From liach at openjdk.org Tue Apr 1 00:02:19 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 1 Apr 2025 00:02:19 GMT Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe [v2] In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 07:01:42 GMT, Nicole Xu wrote: >> The UnsafeOps JMH benchmark fails with the following error: >> >> ``` >> java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426 >> ``` >> >> Since this micro-benchmark is created for `sun.misc.Unsafe` rather than >> `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744. >> >> Note that even it will raise "proprietary API" warnings after this >> patch, it is acceptable because the relevant APIs are bound for removal >> for the integrity of the platform. > > Nicole Xu has updated the pull request incrementally with two additional commits since the last revision: > > - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe > > The UnsafeOps JMH benchmark fails with the following error: > > ``` > java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426 > ``` > > Since this micro-benchmark is created for `sun.misc.Unsafe` rather than > `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744. > > Note that even it will raise "proprietary API" warnings after this > patch, it is acceptable because the relevant APIs are bound for removal > for the integrity of the platform. > > Change-Id: Ia7c57c2ca09af4b2b3c6cc10ef4ae5a9f3c38a4c > - Revert "8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe" > > This reverts commit ebc32ae2c6e448075fedbdbb2b4879c43829c44b. They are compiled by any test task, but they can still fail at run-time. That's why you see mostly fails-at-run fixes in the JDK. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2767676901 From liach at openjdk.org Tue Apr 1 00:31:27 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 1 Apr 2025 00:31:27 GMT Subject: RFR: 8327858: Improve spliterator and forEach for single-element immutable collections [v4] In-Reply-To: References: Message-ID: On Fri, 11 Oct 2024 15:49:33 GMT, Chen Liang wrote: >> Please review this patch that: >> 1. Implemented `forEach` to optimize for 1 or 2 element collections. >> 2. Implemented `spliterator` to optimize for a single element. >> >> The default implementations for multiple-element immutable collections are fine as-is, specializing implementation doesn't provide much benefit. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - s'marks requests > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream > - Add test to ensure reproducible iteration order > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream > - Use the improved form in forEach > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream > - Null checks should probably be in the beginning... > - mark implicit null checks > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream > - ... and 8 more: https://git.openjdk.org/jdk/compare/7276a1be...4f1f4f1b Keep alive... I wonder if this patch that tries to improve functional programming access to immutable small collections has any problem that it lacks a review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15834#issuecomment-2767713089 From liach at openjdk.org Tue Apr 1 00:32:22 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 1 Apr 2025 00:32:22 GMT Subject: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v6] In-Reply-To: References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> Message-ID: On Mon, 31 Mar 2025 14:48:07 GMT, Alan Bateman 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 12 additional commits since the last revision: >> >> - Lance's inputs >> - merge latest from master branch >> - merge latest from master branch >> - merge latest from master branch >> - additional updates to the doc >> - merge latest from master branch >> - change "@implSpec" to "@apiNote" and update their text >> - add class level documentation >> - merge latest from master branch >> - add tests >> - ... and 2 more: https://git.openjdk.org/jdk/compare/442577ad...ed7cf59e > > src/java.base/share/classes/java/util/zip/InflaterOutputStream.java line 89: > >> 87: * @apiNote >> 88: * The default decompressor will be closed when this output stream >> 89: * is {@linkplain #close() closed}. > > This can be normative, meaning you can drop the apiNote. Does the original specification imply a default decompressor is created, or is such a default decompressor simply used? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23655#discussion_r2021945088 From jzaugg at openjdk.org Tue Apr 1 00:59:57 2025 From: jzaugg at openjdk.org (Jason Zaugg) Date: Tue, 1 Apr 2025 00:59:57 GMT Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance [v2] In-Reply-To: References: Message-ID: <8UqLlWwRDd27THNn3oXl2n3LNc6UODiKoPYJa7p3S_0=.c38e4afe-2823-4ffe-9557-01295137930f@github.com> > 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision: 8352642: Also pass zipinfo-time to the alternative newFileSystem call ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24176/files - new: https://git.openjdk.org/jdk/pull/24176/files/eee2f613..e0d40f4d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24176&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24176&range=00-01 Stats: 13 lines in 1 file changed: 8 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24176.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24176/head:pull/24176 PR: https://git.openjdk.org/jdk/pull/24176 From jpai at openjdk.org Tue Apr 1 01:06:21 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 1 Apr 2025 01:06:21 GMT Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed with "RuntimeException: MyObject is not found in test output" [v4] In-Reply-To: References: <5b3b2rpSi55zpNR2AwMgiGZdOklLFwMIJEP-bYxWLGc=.740e5031-952f-4504-bf4b-3ea94881051f@github.com> Message-ID: <2GcX4ppEGMA8M_yrDLV5abYkDJak6FZrUP2IjiaqXqo=.353a1092-b15e-48fa-ae71-fc948462f703@github.com> On Mon, 31 Mar 2025 19:41:29 GMT, Brent Christian wrote: >> test/jdk/java/lang/ref/FinalizerHistogramTest.java line 131: >> >>> 129: volatile boolean ref1Cleared = false; >>> 130: volatile boolean ref2Cleared = false; >>> 131: Thread thread; >> >> Nit: This need not be a field in the class and instead can be local to the constructor where the Thread is started. But it's OK to leave it like this if you prefer to. > > I feel better about maintaining a strong reference (`refQForTwo -> thread`) to the `Thread`. Hello Brent, that's fine with me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24143#discussion_r2021968242 From liach at openjdk.org Tue Apr 1 01:33:15 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 1 Apr 2025 01:33:15 GMT Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance [v2] In-Reply-To: <8UqLlWwRDd27THNn3oXl2n3LNc6UODiKoPYJa7p3S_0=.c38e4afe-2823-4ffe-9557-01295137930f@github.com> References: <8UqLlWwRDd27THNn3oXl2n3LNc6UODiKoPYJa7p3S_0=.c38e4afe-2823-4ffe-9557-01295137930f@github.com> Message-ID: On Tue, 1 Apr 2025 00:59:57 GMT, Jason Zaugg wrote: >> 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance > > Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision: > > 8352642: Also pass zipinfo-time to the alternative newFileSystem call Consistently including this ignore timestamp flag for both paths is indeed better than doing so for only one path. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24176#pullrequestreview-2730858585 From liach at openjdk.org Tue Apr 1 01:59:21 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 1 Apr 2025 01:59:21 GMT Subject: RFR: 8352565: Add native method implementation of Reference.get() In-Reply-To: References: Message-ID: On Sat, 29 Mar 2025 21:47:18 GMT, Kim Barrett wrote: > Please review this change which adds a native method providing the > implementation of Reference::get. Referece::get is an intrinsic candidate, so > this native method implementation is only used when the intrinsic is not. > > Currently there is intrinsic support by the interpreter, C1, C2, and graal, > which are always used. With this change we can later remove all the > per-platform interpreter intrinsic implementations, and might also remove the > C1 intrinsic implementation. > > Testing: > (1) mach5 tier1-6 normal (so using all the existing intrinsics). > (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled. src/java.base/share/classes/java/lang/ref/Reference.java line 365: > 363: * C2 to sometimes prefer the native implementation over the intrinsic. > 364: */ > 365: private native Object get0(); I think you can declare this as `private native T get0();` without changes to native method signatures, so you can avoid the unchecked cast above. (See Class::getPrimitiveClass declaration) Also, can C2 choose to use native over intrinsic? That is concerning from a performance POV, as I think there are a few such performance sensitive methods in core libraries. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2022010819 From iris at openjdk.org Tue Apr 1 04:35:16 2025 From: iris at openjdk.org (Iris Clark) Date: Tue, 1 Apr 2025 04:35:16 GMT Subject: RFR: 8353234: Refactor XMLSecurityPropertyManager In-Reply-To: References: Message-ID: On Mon, 31 Mar 2025 17:42:20 GMT, Joe Wang wrote: > Refactor XMLSecurityPropertyManager. > The Xerces and Xalan components each had its own XMLSecurityManager and XMLSecurityPropertyManager. In a previous fix, the former had been unified as part of that changeset. This change will allow future changes to handle XMLSecurityManager and XMLSecurityPropertyManager in a similar manner. > > No material change has been made to the classes. The new classes were based on the classes in xalan/utils with a methods merged from that in xerces/utils. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24334#pullrequestreview-2731079358 From azeller at openjdk.org Tue Apr 1 05:13:17 2025 From: azeller at openjdk.org (Arno Zeller) Date: Tue, 1 Apr 2025 05:13:17 GMT Subject: RFR: 8352419: Test tools/jpackage/share/ErrorTest.java#id0 and #id1 fail In-Reply-To: <1QksvVOulgv5y1TaYzDy8SomeWoYrGp0WgOU4GhLpwk=.ae5739b3-4ca0-462b-b4d7-4e0d8480572f@github.com> References: <1QksvVOulgv5y1TaYzDy8SomeWoYrGp0WgOU4GhLpwk=.ae5739b3-4ca0-462b-b4d7-4e0d8480572f@github.com> Message-ID: On Fri, 28 Mar 2025 15:02:05 GMT, Alexey Semenyuk wrote: > Make tools/jpackage/share/ErrorTest.java test safely handle the case when native bundling is unavailable on the test host. > > Additionally: > - If native bundling is unavailable on the test host, PackageTest will throw `jtreg.SkippedException` and mark the test as skipped instead of silently doing nothing. This should mark a few jpackage tests "skipped" in tests runs on Alpine Linux that doesn't support either .deb or .rpm packaging. > - Get rid of the dependency on `jtreg.SkippedException` from `/jdk/test` lib as this exception can be thrown from almost every jpackage test because of the changes in PackageTest. Instead embed `jtreg.SkippedException` classfile in TKit.java source and load it from there. This is a less intrusive alternative to adding > > * @library /test/lib > * @build jtreg.SkippedException > > in every jtreg test declaration I see a test failure in tools/jpackage/helpers-test/jdk/jpackage/test/PackageTestTest.java with this PR when I run the test on Alpine without rpm or dpkg installed. The output contains a 82 SSkipped Exceptions like : jtreg.SkippedException: None of the native packagers supported in this environment at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:62) ... at java.base/java.util.ArrayList.forEach(ArrayList.java:1604) And in the end... at java.base/java.util.ArrayList.forEach(ArrayList.java:1604) FAILED jdk.jpackage.test.PackageTestTest::runJPackageTests 'runJPackageTests(Path)' [1593ms] JavaTest Message: JUnit Platform Failure(s): 1 [ JUnit Containers: found 4, started 4, succeeded 4, failed 0, aborted 0, skipped 0] [ JUnit Tests: found 1, started 1, succeeded 0, failed 1, aborted 0, skipped 0] java.lang.Exception: JUnit test failure at com.sun.javatest.regtest.agent.JUnitRunner.runWithJUnitPlatform(JUnitRunner.java:169) at com.sun.javatest.regtest.agent.JUnitRunner.main(JUnitRunner.java:102) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) at java.base/java.lang.Thread.run(Thread.java:1447) JavaTest Message: Test threw exception: java.lang.Exception JavaTest Message: shutting down test ------------- PR Comment: https://git.openjdk.org/jdk/pull/24294#issuecomment-2768113832 From jpai at openjdk.org Tue Apr 1 05:41:09 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 1 Apr 2025 05:41:09 GMT Subject: RFR: 8304674: AttachCurrentThread 's argument is JavaVMAttachArgs In-Reply-To: References: Message-ID: <7it4FHcVaDI_yWSKbTWO_ZQKhFfpy4AjpzN7bsYSRbo=.8920c59f-4189-4362-82c4-3f538c6a7e22@github.com> On Mon, 31 Mar 2025 02:43:45 GMT, tison wrote: >> Hello @tisonkun, is there an issue created for this? https://bugs.openjdk.org/browse/JDK-8304674 against which this PR is linked is for something else. The PR description too isn't clear what this change is about. > > @jaikiran not yet. How can I create an issue for this PR? I don't find some instructions :/ Hello @tisonkun, > How can I create an issue for this PR? I don't find some instructions :/ In general, the OpenJDK contribution guide has these details https://openjdk.org/guide/. Typically, depending on the change, you either raise an issue through https://bugreport.java.com/bugreport/ or you create a discussion in the relevant mailing list. A PR is usually created after there's some consensus about the necessity of the change. For the current PR, David notes that this change was previously discussed and it was decided not to pursue further. If you have further questions or need additional inputs, I recommend that you subscribe to the hotspot-runtime-dev mailing list https://mail.openjdk.org/mailman/listinfo/hotspot-runtime-dev and create a discussion there. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21658#issuecomment-2768151041 From sathishkumar.thiyagarajan at gmail.com Tue Apr 1 05:58:12 2025 From: sathishkumar.thiyagarajan at gmail.com (Sathish Kumar Thiyagarajan) Date: Tue, 1 Apr 2025 11:28:12 +0530 Subject: Reg: Proposal: Generalized Number.parseNumber(String) Method for Java In-Reply-To: References: Message-ID: Sure, Volkan. Let me explain with a sample use case (I also have the source code available on GitHub at https://github.com/sathishk/parse-number ). > When developing *REST APIs or Data Engineering applications*, we often > deal with *untyped JSON documents*, which are loaded into Java as Map Object> (for JSON objects) or List (for JSON arrays). Typically, > JSON parsers convert these into Java objects. Consider this example: Map originalData = Map.of( "byteValue", (byte) 123, "shortValue", (short) 1234 ); This would be represented as the following JSON: { "shortValue": 1234, "byteValue": 123 } Now, when we *deserialize* this JSON using a parser like Jackson : Map deserializedData = new JsonReader().getJacksonMap(jsonString); The expectation is that *numeric values should be preserved in their smallest possible type* (byte or short). However, *Jackson (and most JSON parsers) default to Integer for whole numbers* because they rely on Integer.parseInt(String), which is a safe fallback for most cases. Why Number.parseNumber(String)? If we had a *generalized Number.parseNumber(String) method*, it could intelligently determine the most memory-efficient number type based on the value range. This would help reduce unnecessary memory usage, especially when handling large datasets in *high-performance applications*. Would love to hear your thoughts on this approach! Thanks & Regards, Sathish Kumar Thiyagarajan On Mon, 31 Mar 2025 at 14:56, Volkan Yaz?c? wrote: > Sathish, would you mind elaborating on your use case a bit more, please? > That is, I am not able to see where and how you want to leverage > `Number#parseNumber(String)` in the `testNumberMemoryUsage()` method. > Example: *"I have this test method verifying this behavior of that > application. Given a `Number#parseNumber(String)`, I can improve this as > follows."* > > On Fri, Mar 28, 2025 at 6:31?PM Sathish Kumar Thiyagarajan < > sathishkumar.thiyagarajan at gmail.com> wrote: > >> Dear Core-Libs Dev Team, >> >> *Note:* I have now subscribed to the mailing list and am resending this >> message as advised. >> >> I would like to propose an improvement to the JDK: a *generalized >> Number.parseNumber(String) method*. >> Motivation >> >> Java provides multiple number types (byte, short, int, long, etc.), and >> developers typically choose them based on memory considerations. Currently, >> Java offers String to Number conversions using concrete classes: >> >> - >> >> Long.parseLong(String) >> - >> >> Integer.parseInt(String) >> - >> >> Short.parseShort(String), etc. >> >> While these are useful, Java lacks a *generalized method* that returns >> the most memory-efficient Number representation based on the input, like: >> >> Number.parseNumber(String numberAsText); >> >> Use Case: JSON Serialization >> >> This would be particularly useful in cases like *JSON serialization in >> REST APIs (Using Jackson )*, where >> number types are often altered during serialization/deserialization. >> Consider the following test case: >> >> @Test >> void testNumberMemoryUsage() throws JsonProcessingException { >> ObjectMapper mapper = new ObjectMapper(); >> Map numbersObject = Map.of("aShort", (short) 1234, "aFloat", (float) 1.33); >> >> final String jsonText = mapper.writeValueAsString(numbersObject); >> Map parsedJsonObject = mapper.readValue(jsonText, new TypeReference<>() {}); >> >> // Expected: Short.class | Actual: Integer.class >> assertEquals(Short.class, parsedJsonObject.get("aShort").getClass()); >> >> // Expected: Float.class | Actual: Double.class >> assertEquals(Float.class, parsedJsonObject.get("aFloat").getClass()); >> } >> >> Reference Implementation >> >> Here?s a rough implementation to illustrate the idea: >> >> private static Number parseNumber(final String numberStr) { >> try { >> if (numberStr.contains(".")) { >> double doubleValue = Double.parseDouble(numberStr); >> return (doubleValue >= -Float.MAX_VALUE && doubleValue <= Float.MAX_VALUE) ? >> (float) doubleValue : doubleValue; >> } else { >> long longValue = Long.parseLong(numberStr); >> if (longValue >= Byte.MIN_VALUE && longValue <= Byte.MAX_VALUE) { >> return (byte) longValue; >> } else if (longValue >= Short.MIN_VALUE && longValue <= Short.MAX_VALUE) { >> return (short) longValue; >> } else if (longValue >= Integer.MIN_VALUE && longValue <= Integer.MAX_VALUE) { >> return (int) longValue; >> } else { >> return longValue; >> } >> } >> } catch (NumberFormatException e) { >> return parseBigNumber(numberStr); >> } >> } >> >> private static Number parseBigNumber(final String numberStr) { >> try { >> return new BigInteger(numberStr); // Try BigInteger first >> } catch (NumberFormatException e) { >> // Only create BigDecimal if BigInteger fails >> BigDecimal bd = new BigDecimal(numberStr); >> try { >> // Convert to BigInteger if there's no fraction >> return bd.toBigIntegerExact(); >> } catch (ArithmeticException ex) { >> return bd; // If it's a decimal, return BigDecimal >> } >> } >> } >> >> Would love to hear your thoughts on this proposal. Appreciate your >> feedback and guidance! >> >> Thanks & Regards, >> Sathish Kumar Thiyagarajan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Tue Apr 1 06:01:08 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 1 Apr 2025 06:01:08 GMT Subject: RFR: 8352709: Remove bad timing annotations from WhileOpTest.java In-Reply-To: <0Q-Uv3UES8WHswAMNYLYTC78X5b1MOYpF6PjUc3SSv8=.e68620ff-9b83-4cff-8dc7-a3a52ee859fa@github.com> References: <0Q-Uv3UES8WHswAMNYLYTC78X5b1MOYpF6PjUc3SSv8=.e68620ff-9b83-4cff-8dc7-a3a52ee859fa@github.com> Message-ID: On Mon, 24 Mar 2025 12:17:22 GMT, Leo Korinth wrote: > WhileOpTest.java is a TestNG test (`TestNG.dirs` is set in Find file: `test/jdk/java/util/stream/test/TEST.properties`) > > As such, the `@run main/timeout=240` annotation is ignored. If that was not the case, it would complain about not specifying a main class. The change looks good to me. test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpTest.java line 50: > 48: * @test > 49: * @bug 8071597 8193856 > 50: * @run main/timeout=240 The original change which introduced this `main/timeout` appears to be https://bugs.openjdk.org/browse/JDK-8134459. Going through the RFR of that change https://mail.openjdk.org/pipermail/core-libs-dev/2018-January/050878.html it appears that in addition to this timeout being introduced there was an additional change done to help improve the duration of this test. Plus there's also a comment in that JBS issue that the timeout hadn't been observed for a while (except locally). I think all that explains why this test hasn't been timing out in the presence of this no-op directive. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24193#pullrequestreview-2731184354 PR Review Comment: https://git.openjdk.org/jdk/pull/24193#discussion_r2022189487 From mbaesken at openjdk.org Tue Apr 1 07:18:18 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 1 Apr 2025 07:18:18 GMT Subject: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher ExecutionEnvironment.java for AIX and Linux/musl is brittle [v6] In-Reply-To: References: Message-ID: <2610j3DnhBsX3Wry9hBLV3tzsXknlWYtPWUUN9DkojU=.f569ed0d-324a-4984-95e2-b38d4052de77@github.com> On Fri, 28 Mar 2025 17:04:03 GMT, Joachim Kern wrote: >> The test `testEcoFriendly()` checks if the launcher pollutes the `LD_LIBRARY_PATH` environment variable. >> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not make sense to make this test somehow passing with crude workarounds, which even do not work in any case. It only works when the test is executed by jtreg without explicitly setting `LD_LIBRARY_PATH`. >> >> The problem occurs if the `LD_LIBRARY_PATH` is set from outside, so the test is called with an already set `LD_LIBRARY_PATH`. This means internally the `LD_LIBRARY_PATH` is polluted with the generic pollution on AIX/musl (called A) and the additional jtreg set `LD_LIBRARY_PATH` (called B). >> The result is, the test has A:B in its `LD_LIBRARY_PATH`. Then the test launched a new VM also with an explicitly given `LD_LIBRARY_PATH` (called C). This VM has the resulting `LD_LIBRARY_PATH` A:C which is being reported to the calling Test. >> Now the test compares the returned A:C against the A:B from the test adding the known C. `if (A:C == A:B:C)`. >> Because the test neither knows A nor B, but only C there is now way to program a working comparison. It only works if B is empty meaning the test is not called by jtreg with a preset `LD_LIBRARY_PATH` >> >> Unfortunately we now have to call all tests with a given runtime search path provided in `LD_LIBRARY_PATH`. >> So my proposal is to skip this sub test for aix and musl. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > add symlink comment again, but without solaris Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24055#pullrequestreview-2731702957 From jpai at openjdk.org Tue Apr 1 07:22:45 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 1 Apr 2025 07:22:45 GMT Subject: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v7] In-Reply-To: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> Message-ID: > Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes? > > As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`. > > The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes. > > I'll draft a CSR once we agree on the proposed text. 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 14 additional commits since the last revision: - Alan's input - replace "@apiNote" in favour of formal spec - merge latest from master branch - Lance's inputs - merge latest from master branch - merge latest from master branch - merge latest from master branch - additional updates to the doc - merge latest from master branch - change "@implSpec" to "@apiNote" and update their text - add class level documentation - ... and 4 more: https://git.openjdk.org/jdk/compare/d01ef6e4...f2d08bad ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23655/files - new: https://git.openjdk.org/jdk/pull/23655/files/ed7cf59e..f2d08bad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23655&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23655&range=05-06 Stats: 16812 lines in 328 files changed: 9615 ins; 6003 del; 1194 mod Patch: https://git.openjdk.org/jdk/pull/23655.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23655/head:pull/23655 PR: https://git.openjdk.org/jdk/pull/23655 From jpai at openjdk.org Tue Apr 1 07:22:48 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 1 Apr 2025 07:22:48 GMT Subject: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v6] In-Reply-To: References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> Message-ID: On Mon, 31 Mar 2025 14:49:12 GMT, Alan Bateman 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 12 additional commits since the last revision: >> >> - Lance's inputs >> - merge latest from master branch >> - merge latest from master branch >> - merge latest from master branch >> - additional updates to the doc >> - merge latest from master branch >> - change "@implSpec" to "@apiNote" and update their text >> - add class level documentation >> - merge latest from master branch >> - add tests >> - ... and 2 more: https://git.openjdk.org/jdk/compare/690c3b58...ed7cf59e > > src/java.base/share/classes/java/util/zip/InflaterOutputStream.java line 123: > >> 121: * {@linkplain #close() Closing} this output stream >> 122: * {@linkplain ##decompressor-usage will not close} the given >> 123: * {@linkplain Inflater decompressor}. > > This can be normative too. Thank you Alan for those inputs. I've updated the PR to make this normative in all the 4 class' constructors. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23655#discussion_r2022288963 From jpai at openjdk.org Tue Apr 1 07:25:23 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 1 Apr 2025 07:25:23 GMT Subject: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v6] In-Reply-To: References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> Message-ID: On Tue, 1 Apr 2025 00:29:47 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/util/zip/InflaterOutputStream.java line 89: >> >>> 87: * @apiNote >>> 88: * The default decompressor will be closed when this output stream >>> 89: * is {@linkplain #close() closed}. >> >> This can be normative, meaning you can drop the apiNote. > > Does the original specification imply a default decompressor is created, or is such a default decompressor simply used? Hello Chen, if you mean whether multiple instances of these streams can share the same default decompressor, then no, they can't (and they don't). Each creates its own instance of default decompressor/compressor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23655#discussion_r2022293348 From syan at openjdk.org Tue Apr 1 07:30:46 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 1 Apr 2025 07:30:46 GMT Subject: RFR: 8304674: File java.c compile error with -fsanitize=address -O0 [v2] In-Reply-To: References: Message-ID: > Hi all, > File src/java.base/share/native/libjli/java.c compile error: control reaches end of non-void function [-Werror=return-type] with gcc options -fsanitize=address -O0. The function int JavaMain(void* _args) in this file will execute return ret in LEAVE() macro, but gcc with -O0 is not smart enough to recognized that the function already has return statement before at the end of function. It's a gcc bug which has been recorded by [80959](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80959), and below code snippet can demonstrate the gcc bug. I think we should disable return-type gcc warning for java.c file before the gcc bug has been fixed. Risk is low. > > >> cat java.c > char a() { > return 0; > int b; > if (a(&b)) > return 0; > } > >> gcc -O0 -Wall -Wextra -Werror -O0 -c java.c -fsanitize=address > java.c: In function ?a?: > java.c:6:1: error: control reaches end of non-void function [-Werror=return-type] > 6 | } > | ^ > cc1: all warnings being treated as errors SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Use #pragma GCC diagnostic ignored "-Wreturn-type" instead of use diasable_warning in makefile ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24318/files - new: https://git.openjdk.org/jdk/pull/24318/files/78785e27..83beb975 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24318&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24318&range=00-01 Stats: 4 lines in 2 files changed: 3 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24318.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24318/head:pull/24318 PR: https://git.openjdk.org/jdk/pull/24318 From syan at openjdk.org Tue Apr 1 07:30:46 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 1 Apr 2025 07:30:46 GMT Subject: RFR: 8304674: File java.c compile error with -fsanitize=address -O0 In-Reply-To: <5XLdWLua54uHwdnZst3xc89s1ipMJijjEEWvN8jHavc=.d70404aa-ab13-4e91-ab42-aa173516b07e@github.com> References: <5XLdWLua54uHwdnZst3xc89s1ipMJijjEEWvN8jHavc=.d70404aa-ab13-4e91-ab42-aa173516b07e@github.com> Message-ID: On Mon, 31 Mar 2025 12:57:38 GMT, Magnus Ihse Bursie wrote: > While I normally advocate using DISABLE_WARNING in makefiles instead of pragmas, in this particular case I wonder if not a pragma in the `LEAVE` macro would be better? PR has been changed to use `#pragma GCC diagnostic ignored "-Wreturn-type"` instead of used DISABLE_WARNING in makefile. Change has been verified locally. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24318#issuecomment-2768435238 From jkern at openjdk.org Tue Apr 1 08:12:24 2025 From: jkern at openjdk.org (Joachim Kern) Date: Tue, 1 Apr 2025 08:12:24 GMT Subject: Integrated: 8352046: Test testEcoFriendly() in jdk tools launcher ExecutionEnvironment.java for AIX and Linux/musl is brittle In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 11:47:44 GMT, Joachim Kern wrote: > The test `testEcoFriendly()` checks if the launcher pollutes the `LD_LIBRARY_PATH` environment variable. > Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not make sense to make this test somehow passing with crude workarounds, which even do not work in any case. It only works when the test is executed by jtreg without explicitly setting `LD_LIBRARY_PATH`. > > The problem occurs if the `LD_LIBRARY_PATH` is set from outside, so the test is called with an already set `LD_LIBRARY_PATH`. This means internally the `LD_LIBRARY_PATH` is polluted with the generic pollution on AIX/musl (called A) and the additional jtreg set `LD_LIBRARY_PATH` (called B). > The result is, the test has A:B in its `LD_LIBRARY_PATH`. Then the test launched a new VM also with an explicitly given `LD_LIBRARY_PATH` (called C). This VM has the resulting `LD_LIBRARY_PATH` A:C which is being reported to the calling Test. > Now the test compares the returned A:C against the A:B from the test adding the known C. `if (A:C == A:B:C)`. > Because the test neither knows A nor B, but only C there is now way to program a working comparison. It only works if B is empty meaning the test is not called by jtreg with a preset `LD_LIBRARY_PATH` > > Unfortunately we now have to call all tests with a given runtime search path provided in `LD_LIBRARY_PATH`. > So my proposal is to skip this sub test for aix and musl. This pull request has now been integrated. Changeset: 196334fc Author: Joachim Kern URL: https://git.openjdk.org/jdk/commit/196334fc395c63e59167ccd85415d8e1d2bcb705 Stats: 59 lines in 1 file changed: 4 ins; 40 del; 15 mod 8352046: Test testEcoFriendly() in jdk tools launcher ExecutionEnvironment.java for AIX and Linux/musl is brittle Reviewed-by: clanger, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/24055 From volkan at yazi.ci Tue Apr 1 08:42:11 2025 From: volkan at yazi.ci (=?UTF-8?B?Vm9sa2FuIFlhesSxY8Sx?=) Date: Tue, 1 Apr 2025 10:42:11 +0200 Subject: Reg: Proposal: Generalized Number.parseNumber(String) Method for Java In-Reply-To: References: Message-ID: Sathish, please see my response below. On Tue, Apr 1, 2025 at 7:58?AM Sathish Kumar Thiyagarajan < sathishkumar.thiyagarajan at gmail.com> wrote: > However, *Jackson (and most JSON parsers) default to Integer for whole > numbers* because they rely on Integer.parseInt(String), which is a safe > fallback for most cases. > AFAIK, almost all JSON parsers use their own number codecs; i.e., encoders and decoders. In the context of Jackson, `new ObjectMapper().readValue("1", Number.class)` ends up in `com.fasterxml.jackson.core.io.NumberInput::parseInt`, not `Integer::parseInt`. There are multiple reasons for such libraries to roll out their own number codecs; performance, matching the internal string representation of library's choice, etc. It is very unlikely adding a `Number::parseNumber` will bring any benefit to such use cases. [Quoting from another post ] It is better to frame feedback in the form of *"I?ve tried this, and run into the following problem ..."* At the very least it helps us see what problems people actually run into as opposed to what problems people speculate that they or others may run into. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkern at openjdk.org Tue Apr 1 09:23:32 2025 From: jkern at openjdk.org (Joachim Kern) Date: Tue, 1 Apr 2025 09:23:32 GMT Subject: RFR: 8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH Message-ID: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so. The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed. ------------- Commit messages: - JDK-8352935 Changes: https://git.openjdk.org/jdk/pull/24351/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24351&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352935 Stats: 6 lines in 3 files changed: 0 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24351.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24351/head:pull/24351 PR: https://git.openjdk.org/jdk/pull/24351 From tschatzl at openjdk.org Tue Apr 1 09:24:12 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 1 Apr 2025 09:24:12 GMT Subject: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v29] 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 37 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into submit/8342382-card-table-instead-of-dcq - * make young gen length revising independent of refinement thread * use a service task * both refinement control thread and young gen length revising use the same infrastructure to get the number of available bytes and determine the time to the next update - * fix IR code generation tests that change due to barrier cost changes - * factor out card table and refinement table merging into a single method - Merge branch 'master' into 8342382-card-table-instead-of-dcq3 - * obsolete G1UpdateBufferSize G1UpdateBufferSize has previously been used to size the refinement buffers and impose a minimum limit on the number of cards per thread that need to be pending before refinement starts. The former function is now obsolete with the removal of the dirty card queues, the latter functionality has been taken over by the new diagnostic option `G1PerThreadPendingCardThreshold`. I prefer to make this a diagnostic option is better than a product option because it is something that is only necessary for some test cases to produce some otherwise unwanted behavior (continuous refinement). CSR is pending. - * more documentation on why we need to rendezvous the gc threads - Merge branch 'master' into 8342381-card-table-instead-of-dcq - ... and 27 more: https://git.openjdk.org/jdk/compare/aff5aa72...51fb6e63 ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=28 Stats: 7089 lines in 110 files changed: 2610 ins; 3555 del; 924 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 sgehwolf at openjdk.org Tue Apr 1 09:29:20 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 1 Apr 2025 09:29:20 GMT Subject: RFR: 8352689: Allow for hash sum overrides when linking from the run-time image [v2] In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 14:50:11 GMT, Alan Bateman wrote: >>> > The cacerts issue mentioned in the JBS issue relates to an RPM installation of the JDK where the cacerts file is a symlink to the distro provided one. So I think that's "use system" issue. >>> > TZ updates would potentially break this too. If an external tool updates `tzdb.dat` then the hash sum computed at JDK build-time will no longer match. I believe this could also be solved with a sha-override (e.g. by coming from a file `@${java.home}/sha-override.txt`) which would get the update along with `tzdb.dat`. >>> >>> I think one direction to explore is configuring which files or directory are "upgradable". Upgradable modules aren't excluded from the hash computation to allow upgrade via the upgrade module path. Something similar here would allow jlink to report that tzdb.dat has been upgraded. Maybe cacerts is the same but need to look closer as the hash computation shouldn't be following sym links outside of the runtime image. >> >> I'll keep looking into this specific case. However, it sounds a bit orthogonal to the patch at hand which I do believe we still need for the original reasons mentioned (RPM changing binaries after the JDK build is long done and the windows issue of the JDK build itself placing different *.pdb files into the image than was present at jlink time). So perhaps we should explore this in parallel? > >> I'll keep looking into this specific case. However, it sounds a bit orthogonal to the patch at hand which I do believe we still need for the original reasons mentioned (RPM changing binaries after the JDK build is long done and the windows issue of the JDK build itself placing different *.pdb files into the image than was present at jlink time). So perhaps we should explore this in parallel? > > I think upgradable files is something we can deal with. I'm not sure yet on the PDB issue, need to think more about about the scenarios to see what might make sense. @AlanBateman Any more thoughts on this? We'd need to include a patch like this one for getting the Fedora JDK 24+ builds to work with JEP 493 enabled. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24190#issuecomment-2768744746 From pminborg at openjdk.org Tue Apr 1 09:36:17 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 1 Apr 2025 09:36:17 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v23] In-Reply-To: References: Message-ID: > Implement JEP 502. > > The PR passes tier1-tier3 tests. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Add benchmarks and update copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23972/files - new: https://git.openjdk.org/jdk/pull/23972/files/df4ef35c..f7f10fa1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=21-22 Stats: 28 lines in 7 files changed: 13 ins; 2 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/23972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 PR: https://git.openjdk.org/jdk/pull/23972 From kbarrett at openjdk.org Tue Apr 1 09:43:28 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 1 Apr 2025 09:43:28 GMT Subject: RFR: 8352565: Add native method implementation of Reference.get() [v2] In-Reply-To: References: Message-ID: > Please review this change which adds a native method providing the > implementation of Reference::get. Referece::get is an intrinsic candidate, so > this native method implementation is only used when the intrinsic is not. > > Currently there is intrinsic support by the interpreter, C1, C2, and graal, > which are always used. With this change we can later remove all the > per-platform interpreter intrinsic implementations, and might also remove the > C1 intrinsic implementation. > > Testing: > (1) mach5 tier1-6 normal (so using all the existing intrinsics). > (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled. Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: parameterized return type of native get0 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24315/files - new: https://git.openjdk.org/jdk/pull/24315/files/f1734062..37dc9b74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24315&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24315&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24315/head:pull/24315 PR: https://git.openjdk.org/jdk/pull/24315 From kbarrett at openjdk.org Tue Apr 1 09:58:15 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 1 Apr 2025 09:58:15 GMT Subject: RFR: 8352565: Add native method implementation of Reference.get() [v2] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 01:54:13 GMT, Chen Liang wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> parameterized return type of native get0 > > src/java.base/share/classes/java/lang/ref/Reference.java line 365: > >> 363: * C2 to sometimes prefer the native implementation over the intrinsic. >> 364: */ >> 365: private native Object get0(); > > I think you can declare this as `private native T get0();` without changes to native method signatures, so you can avoid the unchecked cast above. (See Class::getPrimitiveClass declaration) > > Also, can C2 choose to use native over intrinsic? That is concerning from a performance POV, as I think there are a few such performance sensitive methods in core libraries. It hadn't occurred to me that would work, but indeed it does. Thanks for the suggestion. I've used tools like `-XX:+PrintInlining` when running a test that I found to be performance sensitive to the use of the intrinsic, and found that it was used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2022537959 From pminborg at openjdk.org Tue Apr 1 10:02:50 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 1 Apr 2025 10:02:50 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v24] In-Reply-To: References: Message-ID: <5OJvCICcMF02tdxdwIh2WLgMqZl5IHgwpYyX47ZAV70=.1a7b42c5-fadd-4fbd-a2e6-c72a2a850fd3@github.com> > Implement JEP 502. > > The PR passes tier1-tier3 tests. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Add additional benchmarks with maps holding method handles ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23972/files - new: https://git.openjdk.org/jdk/pull/23972/files/f7f10fa1..dfb940be Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=22-23 Stats: 16 lines in 1 file changed: 16 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 PR: https://git.openjdk.org/jdk/pull/23972 From pminborg at openjdk.org Tue Apr 1 10:06:43 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 1 Apr 2025 10:06:43 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6] In-Reply-To: References: Message-ID: On Mon, 17 Mar 2025 02:35:01 GMT, Chen Liang wrote: >> src/hotspot/share/ci/ciField.cpp line 254: >> >>> 252: >>> 253: static bool trust_final_non_static_fields_of_type(Symbol* signature) { >>> 254: return signature == vmSymbols::java_lang_StableValue_signature(); >> >> Just a note that we will need to decide whether to keep this or not... > > We might change this to require stable values to be strict final instead if strict final is previewed at the same time as stable values - https://openjdk.org/jeps/8350458 This has now been removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2022552862 From pminborg at openjdk.org Tue Apr 1 10:14:49 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 1 Apr 2025 10:14:49 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6] In-Reply-To: References: Message-ID: On Mon, 17 Mar 2025 02:56:11 GMT, Chen Liang wrote: >> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits: >> >> - Merge branch 'master' into implement-jep502 >> - Clean up exception messages and fix comments >> - Rename field >> - Rename method and fix comment >> - Rework reenterant logic >> - Use acquire semantics for reading rather than volatile semantics >> - Add missing null check >> - Simplify handling of sentinel, wrap, and unwrap >> - Fix JavaDoc issues >> - Fix members in StableEnumFunction >> - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f > > src/java.base/share/classes/java/lang/StableValue.java line 56: > >> 54: * , {@linkplain #orElse(Object) orElse()}, or {@linkplain #orElseSet(Supplier) orElseSet()}. >> 55: *

>> 56: * A stable value that is set is treated as a constant by the JVM, enabling the > > Before promoting the "constant" features, I would prefer more details about the transition to set - that setting is really a racy thing and only one actor succeeds in setting, and specify the memory effect (like the final field freeze) as a hb for the set and all subsequent gets that successfully observed that set. This is handled in the section "thread-safety" a bit down in the docs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2022563882 From mcimadamore at openjdk.org Tue Apr 1 10:27:28 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 1 Apr 2025 10:27:28 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v21] In-Reply-To: <14unTVqrBXjhB_DYk7CpK5eXmCy_CU7LgaJ0MvLkuis=.515d378c-288f-4cbf-b92e-83d2cf81eb20@github.com> References: <5BpPdjiai-EEyaut13cxuVnuow-AQUMnB7mBHd7on5Q=.70a81283-6779-45b4-9fc9-e6b911f42b2a@github.com> <14unTVqrBXjhB_DYk7CpK5eXmCy_CU7LgaJ0MvLkuis=.515d378c-288f-4cbf-b92e-83d2cf81eb20@github.com> Message-ID: <-i6wri7KZevx7b_OXtSTcZq1skCfK8jxbODZ0x59MZc=.6e869864-1c7c-4e9c-9816-6a8d1d19470d@github.com> On Mon, 31 Mar 2025 16:03:57 GMT, Per Minborg wrote: > Here are the results of the new `MethodHandle` benchmarks: > > ``` > Benchmark Mode Cnt Score Error Units > StableMethodHandleBenchmark.atomic avgt 10 3.676 ? 0.206 ns/op > StableMethodHandleBenchmark.dcl avgt 10 3.766 ? 0.181 ns/op > StableMethodHandleBenchmark.finalMh avgt 10 0.693 ? 0.015 ns/op > StableMethodHandleBenchmark.map avgt 10 7.648 ? 0.308 ns/op > StableMethodHandleBenchmark.nonFinalMh avgt 10 3.381 ? 0.485 ns/op > StableMethodHandleBenchmark.stableMap avgt 10 0.713 ? 0.016 ns/op > StableMethodHandleBenchmark.stableMh avgt 10 0.700 ? 0.030 ns/op > ``` Thanks - I think this shows very clearly what this API is all about ;-) E.g. fast access is one part of the equation, but constant-folding of the accessed result is another very important property. When combined, they allow the kind of performance shown in this benchmark. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2768892425 From lkorinth at openjdk.org Tue Apr 1 10:56:48 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 1 Apr 2025 10:56:48 GMT Subject: Integrated: 8352709: Remove bad timing annotations from WhileOpTest.java In-Reply-To: <0Q-Uv3UES8WHswAMNYLYTC78X5b1MOYpF6PjUc3SSv8=.e68620ff-9b83-4cff-8dc7-a3a52ee859fa@github.com> References: <0Q-Uv3UES8WHswAMNYLYTC78X5b1MOYpF6PjUc3SSv8=.e68620ff-9b83-4cff-8dc7-a3a52ee859fa@github.com> Message-ID: On Mon, 24 Mar 2025 12:17:22 GMT, Leo Korinth wrote: > WhileOpTest.java is a TestNG test (`TestNG.dirs` is set in Find file: `test/jdk/java/util/stream/test/TEST.properties`) > > As such, the `@run main/timeout=240` annotation is ignored. If that was not the case, it would complain about not specifying a main class. This pull request has now been integrated. Changeset: 6801eb87 Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/6801eb87042742b8d760b79900b2bdff97c321b1 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8352709: Remove bad timing annotations from WhileOpTest.java Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/24193 From lkorinth at openjdk.org Tue Apr 1 10:56:47 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 1 Apr 2025 10:56:47 GMT Subject: RFR: 8352709: Remove bad timing annotations from WhileOpTest.java In-Reply-To: <0Q-Uv3UES8WHswAMNYLYTC78X5b1MOYpF6PjUc3SSv8=.e68620ff-9b83-4cff-8dc7-a3a52ee859fa@github.com> References: <0Q-Uv3UES8WHswAMNYLYTC78X5b1MOYpF6PjUc3SSv8=.e68620ff-9b83-4cff-8dc7-a3a52ee859fa@github.com> Message-ID: On Mon, 24 Mar 2025 12:17:22 GMT, Leo Korinth wrote: > WhileOpTest.java is a TestNG test (`TestNG.dirs` is set in Find file: `test/jdk/java/util/stream/test/TEST.properties`) > > As such, the `@run main/timeout=240` annotation is ignored. If that was not the case, it would complain about not specifying a main class. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24193#issuecomment-2768969517 From jlahoda at openjdk.org Tue Apr 1 11:22:22 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 1 Apr 2025 11:22:22 GMT Subject: RFR: 8352693: Use a simpler console reader instead of JLine for System.console() In-Reply-To: References: Message-ID: <--xCs-W_bE8JdYjHC9nAU1gfTX_JGB98nzi-_VAaE6s=.5ea1f212-ab4c-4b30-80af-08061e7ebdb0@github.com> On Mon, 31 Mar 2025 17:22:45 GMT, David M. Lloyd wrote: >> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell. >> >> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend. >> >> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior. > > src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java line 75: > >> 73: } >> 74: continue READ; >> 75: case '\033': > > If this is meant to be platform-agnostic, is it really safe to make these assumptions about the ability to produce or interpret escape codes and to make assumptions about their behavior on the user's terminal? I don't think it would even be safe to assume a single terminal type or interpretation on POSIX-type OSes; that's what things like `terminfo`/`termcap` are supposed to be for, right? In theory, yes, that's what `terminfo` is supposed to do. But `terminfo` has its own set of problems, and what we get from a terminal and what we send to the terminal is so simple and generally supported, that it should be possible to make it work on all realistic terminals(*). Or is there a particular terminal you have in mind? (*) I admit I've forgot that `\E[7~`/`\E[8~` is Home/End as well. I'll fix that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2022656839 From alanb at openjdk.org Tue Apr 1 11:45:19 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 1 Apr 2025 11:45:19 GMT Subject: RFR: 8353331: Test ForkJoinPool20Test::testFixedDelaySequence is failing Message-ID: ForkJoinPool20Test::testFixedDelaySequence is failing intermittently. The assert that checks that the periodically tasks only executes 8 times is removed, it may run more than this before it cancelled. ------------- Commit messages: - Drop assert Changes: https://git.openjdk.org/jdk/pull/24353/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24353&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353331 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24353/head:pull/24353 PR: https://git.openjdk.org/jdk/pull/24353 From dl at openjdk.org Tue Apr 1 11:45:19 2025 From: dl at openjdk.org (Doug Lea) Date: Tue, 1 Apr 2025 11:45:19 GMT Subject: RFR: 8353331: Test ForkJoinPool20Test::testFixedDelaySequence is failing In-Reply-To: References: Message-ID: <3ypSv6ntiVjChBwQ2cOyKwiL0hF_1kMQ-9WzfjGFh9U=.7c5d8fa3-3051-4b7a-96d6-16ebfacd3958@github.com> On Tue, 1 Apr 2025 10:56:25 GMT, Alan Bateman wrote: > ForkJoinPool20Test::testFixedDelaySequence is failing intermittently. The assert that checks that the periodically tasks only executes 8 times is removed, it may run more than this before it cancelled. Yes, the bound is no longer guaranteed after adapting this test from STPE. ------------- Marked as reviewed by dl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24353#pullrequestreview-2732388145 From syan at openjdk.org Tue Apr 1 12:07:09 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 1 Apr 2025 12:07:09 GMT Subject: RFR: 8304674: File java.c compile error with -fsanitize=address -O0 [v3] In-Reply-To: References: Message-ID: > Hi all, > File src/java.base/share/native/libjli/java.c compile error: control reaches end of non-void function [-Werror=return-type] with gcc options -fsanitize=address -O0. The function int JavaMain(void* _args) in this file will execute return ret in LEAVE() macro, but gcc with -O0 is not smart enough to recognized that the function already has return statement before at the end of function. It's a gcc bug which has been recorded by [80959](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80959), and below code snippet can demonstrate the gcc bug. I think we should disable return-type gcc warning for java.c file before the gcc bug has been fixed. Risk is low. > > >> cat java.c > char a() { > return 0; > int b; > if (a(&b)) > return 0; > } > >> gcc -O0 -Wall -Wextra -Werror -O0 -c java.c -fsanitize=address > java.c: In function ?a?: > java.c:6:1: error: control reaches end of non-void function [-Werror=return-type] > 6 | } > | ^ > cc1: all warnings being treated as errors SendaoYan has updated the pull request incrementally with one additional commit since the last revision: add "#if defined(__GNUC__)" to fix windows build warning ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24318/files - new: https://git.openjdk.org/jdk/pull/24318/files/83beb975..8d929c8d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24318&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24318&range=01-02 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24318.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24318/head:pull/24318 PR: https://git.openjdk.org/jdk/pull/24318 From vklang at openjdk.org Tue Apr 1 12:30:10 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 1 Apr 2025 12:30:10 GMT Subject: RFR: 8353331: Test ForkJoinPool20Test::testFixedDelaySequence is failing In-Reply-To: References: Message-ID: <8IgNfXxsSfKkqwcaI2x9dSE4TBkRpk9ocYSOxLzI5gI=.a55419e5-8468-40a9-9bd1-9741d70ec792@github.com> On Tue, 1 Apr 2025 10:56:25 GMT, Alan Bateman wrote: > ForkJoinPool20Test::testFixedDelaySequence is failing intermittently. The assert that checks that the periodically tasks only executes 8 times is removed, it may run more than this before it cancelled. Marked as reviewed by vklang (Reviewer). Thanks for fixing this, @AlanBateman ------------- PR Review: https://git.openjdk.org/jdk/pull/24353#pullrequestreview-2732518687 PR Comment: https://git.openjdk.org/jdk/pull/24353#issuecomment-2769194218 From alanb at openjdk.org Tue Apr 1 12:45:16 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 1 Apr 2025 12:45:16 GMT Subject: Integrated: 8353331: Test ForkJoinPool20Test::testFixedDelaySequence is failing In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 10:56:25 GMT, Alan Bateman wrote: > ForkJoinPool20Test::testFixedDelaySequence is failing intermittently. The assert that checks that the periodically tasks only executes 8 times is removed, it may run more than this before it cancelled. This pull request has now been integrated. Changeset: 2a31f69a Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/2a31f69a55b64358a347b2cbc2c4df1890dd6840 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8353331: Test ForkJoinPool20Test::testFixedDelaySequence is failing Reviewed-by: dl, vklang ------------- PR: https://git.openjdk.org/jdk/pull/24353 From liach at openjdk.org Tue Apr 1 13:26:22 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 1 Apr 2025 13:26:22 GMT Subject: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v6] In-Reply-To: References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> Message-ID: <7cJ7S9sIDrpnWSLyQRh7kD4myMQNOT89AqUtNCMk48s=.0545e3ce-5db4-4db3-8fe4-949f9ec39e79@github.com> On Tue, 1 Apr 2025 07:22:57 GMT, Jaikiran Pai wrote: >> Does the original specification imply a default decompressor is created, or is such a default decompressor simply used? > > Hello Chen, if you mean whether multiple instances of these streams can share the same default decompressor, then no, they can't (and they don't). Each creates its own instance of default decompressor/compressor. Is it impossible for another compliant implementation of Java SE to do so? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23655#discussion_r2022851311 From pminborg at openjdk.org Tue Apr 1 13:27:34 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 1 Apr 2025 13:27:34 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v25] In-Reply-To: References: Message-ID: > Implement JEP 502. > > The PR passes tier1-tier3 tests. Per Minborg has updated the pull request incrementally with two additional commits since the last revision: - Add lazy toSting for StableMap::values - Make toString for reversed and sublist lazy ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23972/files - new: https://git.openjdk.org/jdk/pull/23972/files/dfb940be..be84045a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=23-24 Stats: 122 lines in 5 files changed: 101 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/23972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 PR: https://git.openjdk.org/jdk/pull/23972 From ihse at openjdk.org Tue Apr 1 13:29:17 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 1 Apr 2025 13:29:17 GMT Subject: RFR: 8353458: Don't pass -Wno-format-nonliteral to CFLAGS Message-ID: The proper way to disable warnings is to use the DISABLED_WARNINGS arguments. In this particular case, there was already a pragma but due to incorrect restrictions it did not apply to clang. ------------- Commit messages: - 8353458: Don't pass -Wno-format-nonliteral to CFLAGS Changes: https://git.openjdk.org/jdk/pull/24357/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24357&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353458 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24357/head:pull/24357 PR: https://git.openjdk.org/jdk/pull/24357 From azeller at openjdk.org Tue Apr 1 14:23:26 2025 From: azeller at openjdk.org (Arno Zeller) Date: Tue, 1 Apr 2025 14:23:26 GMT Subject: RFR: 8352419: Test tools/jpackage/share/ErrorTest.java#id0 and #id1 fail In-Reply-To: <1QksvVOulgv5y1TaYzDy8SomeWoYrGp0WgOU4GhLpwk=.ae5739b3-4ca0-462b-b4d7-4e0d8480572f@github.com> References: <1QksvVOulgv5y1TaYzDy8SomeWoYrGp0WgOU4GhLpwk=.ae5739b3-4ca0-462b-b4d7-4e0d8480572f@github.com> Message-ID: On Fri, 28 Mar 2025 15:02:05 GMT, Alexey Semenyuk wrote: > Make tools/jpackage/share/ErrorTest.java test safely handle the case when native bundling is unavailable on the test host. > > Additionally: > - If native bundling is unavailable on the test host, PackageTest will throw `jtreg.SkippedException` and mark the test as skipped instead of silently doing nothing. This should mark a few jpackage tests "skipped" in tests runs on Alpine Linux that doesn't support either .deb or .rpm packaging. > - Get rid of the dependency on `jtreg.SkippedException` from `/jdk/test` lib as this exception can be thrown from almost every jpackage test because of the changes in PackageTest. Instead embed `jtreg.SkippedException` classfile in TKit.java source and load it from there. This is a less intrusive alternative to adding > > * @library /test/lib > * @build jtreg.SkippedException > > in every jtreg test declaration The same issue can be seen on a Windows system without WIX installed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24294#issuecomment-2769546111 From jpai at openjdk.org Tue Apr 1 14:25:09 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 1 Apr 2025 14:25:09 GMT Subject: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v6] In-Reply-To: <7cJ7S9sIDrpnWSLyQRh7kD4myMQNOT89AqUtNCMk48s=.0545e3ce-5db4-4db3-8fe4-949f9ec39e79@github.com> References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> <7cJ7S9sIDrpnWSLyQRh7kD4myMQNOT89AqUtNCMk48s=.0545e3ce-5db4-4db3-8fe4-949f9ec39e79@github.com> Message-ID: On Tue, 1 Apr 2025 13:24:08 GMT, Chen Liang wrote: >> Hello Chen, if you mean whether multiple instances of these streams can share the same default decompressor, then no, they can't (and they don't). Each creates its own instance of default decompressor/compressor. > > Is it impossible for another compliant implementation of Java SE to do so? It's hard for me to guess what prompted that question, but I'll take a guess - are you asking this question to decide whether we should reword the pre-existing javadoc on these constructors to explicitly state that a new decompressor/compressor instance gets created for each instance of the stream? If so, then my opinion is that we shouldn't change that part of the existing doc. If you meant something else, then please add the details and we can decide if any additional changes are necessary to the text. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23655#discussion_r2022969583 From duke at openjdk.org Tue Apr 1 14:26:48 2025 From: duke at openjdk.org (David M. Lloyd) Date: Tue, 1 Apr 2025 14:26:48 GMT Subject: RFR: 8352693: Use a simpler console reader instead of JLine for System.console() In-Reply-To: <--xCs-W_bE8JdYjHC9nAU1gfTX_JGB98nzi-_VAaE6s=.5ea1f212-ab4c-4b30-80af-08061e7ebdb0@github.com> References: <--xCs-W_bE8JdYjHC9nAU1gfTX_JGB98nzi-_VAaE6s=.5ea1f212-ab4c-4b30-80af-08061e7ebdb0@github.com> Message-ID: On Tue, 1 Apr 2025 11:18:14 GMT, Jan Lahoda wrote: >> src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java line 75: >> >>> 73: } >>> 74: continue READ; >>> 75: case '\033': >> >> If this is meant to be platform-agnostic, is it really safe to make these assumptions about the ability to produce or interpret escape codes and to make assumptions about their behavior on the user's terminal? I don't think it would even be safe to assume a single terminal type or interpretation on POSIX-type OSes; that's what things like `terminfo`/`termcap` are supposed to be for, right? > > In theory, yes, that's what `terminfo` is supposed to do. But `terminfo` has its own set of problems, and what we get from a terminal and what we send to the terminal is so simple and generally supported, that it should be possible to make it work on all realistic terminals(*). Or is there a particular terminal you have in mind? > > (*) I admit I've forgot that `\E[7~`/`\E[8~` is Home/End as well. I'll fix that. I suppose I don't have a particular terminal in mind. But at the very least, maybe some documentation somewhere should reference e.g. [ECMA-48](https://ecma-international.org/publications-and-standards/standards/ecma-48/) as the basis for the behaviors of the console? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2022971819 From liach at openjdk.org Tue Apr 1 14:53:23 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 1 Apr 2025 14:53:23 GMT Subject: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v6] In-Reply-To: References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> <7cJ7S9sIDrpnWSLyQRh7kD4myMQNOT89AqUtNCMk48s=.0545e3ce-5db4-4db3-8fe4-949f9ec39e79@github.com> Message-ID: On Tue, 1 Apr 2025 14:22:22 GMT, Jaikiran Pai wrote: >> Is it impossible for another compliant implementation of Java SE to do so? > > It's hard for me to guess what prompted that question, but I'll take a guess - are you asking this question to decide whether we should reword the pre-existing javadoc on these constructors to explicitly state that a new decompressor/compressor instance gets created for each instance of the stream? If so, then my opinion is that we shouldn't change that part of the existing doc. > > If you meant something else, then please add the details and we can decide if any additional changes are necessary to the text. My opinion is that: if it is possible for another implementation to share the backing in/deflator (such as via thread-local instances) that does not always need to be closed when an in/output stream is closed, then we should not specify in a way that rules out such an implementation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23655#discussion_r2023022774 From sgehwolf at openjdk.org Tue Apr 1 14:59:37 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 1 Apr 2025 14:59:37 GMT Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics [v17] In-Reply-To: References: Message-ID: > Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes. > > For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`). > > This patch addresses this issue by: > > 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2. > 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value). > > As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems. > > This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been added in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests. > > Thoughts? > > Testing: > > - [x] GHA > - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems > - [x] Some manual testing using systemd slices Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: - Merge branch 'master' into jdk-8336881-metrics-systemd-slice - JDK-8350103 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice - Merge branch 'master' into jdk-8336881-metrics-systemd-slice - Fix missing imports - Merge branch 'master' into jdk-8336881-metrics-systemd-slice - Merge branch 'master' into jdk-8336881-metrics-systemd-slice - Merge branch 'master' into jdk-8336881-metrics-systemd-slice - Merge branch 'master' into jdk-8336881-metrics-systemd-slice - Merge branch 'master' into jdk-8336881-metrics-systemd-slice - ... and 34 more: https://git.openjdk.org/jdk/compare/6801eb87...32960cd6 ------------- Changes: https://git.openjdk.org/jdk/pull/20280/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=16 Stats: 1621 lines in 27 files changed: 1373 ins; 152 del; 96 mod Patch: https://git.openjdk.org/jdk/pull/20280.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20280/head:pull/20280 PR: https://git.openjdk.org/jdk/pull/20280 From asemenyuk at openjdk.org Tue Apr 1 15:19:33 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 1 Apr 2025 15:19:33 GMT Subject: RFR: 8352419: Test tools/jpackage/share/ErrorTest.java#id0 and #id1 fail In-Reply-To: <1QksvVOulgv5y1TaYzDy8SomeWoYrGp0WgOU4GhLpwk=.ae5739b3-4ca0-462b-b4d7-4e0d8480572f@github.com> References: <1QksvVOulgv5y1TaYzDy8SomeWoYrGp0WgOU4GhLpwk=.ae5739b3-4ca0-462b-b4d7-4e0d8480572f@github.com> Message-ID: <2SRdh831mtr1Dh4myuoFhBROPvqCbxdySZIIjZKy6Fo=.268bca67-60a1-4aab-bfdf-da24b13b0ba8@github.com> On Fri, 28 Mar 2025 15:02:05 GMT, Alexey Semenyuk wrote: > Make tools/jpackage/share/ErrorTest.java test safely handle the case when native bundling is unavailable on the test host. > > Additionally: > - If native bundling is unavailable on the test host, PackageTest will throw `jtreg.SkippedException` and mark the test as skipped instead of silently doing nothing. This should mark a few jpackage tests "skipped" in tests runs on Alpine Linux that doesn't support either .deb or .rpm packaging. > - Get rid of the dependency on `jtreg.SkippedException` from `/jdk/test` lib as this exception can be thrown from almost every jpackage test because of the changes in PackageTest. Instead embed `jtreg.SkippedException` classfile in TKit.java source and load it from there. This is a less intrusive alternative to adding > > * @library /test/lib > * @build jtreg.SkippedException > > in every jtreg test declaration Good catch. I'll work on the fix ------------- PR Comment: https://git.openjdk.org/jdk/pull/24294#issuecomment-2769720548 From erikj at openjdk.org Tue Apr 1 15:46:17 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 1 Apr 2025 15:46:17 GMT Subject: RFR: 8353458: Don't pass -Wno-format-nonliteral to CFLAGS In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 13:22:47 GMT, Magnus Ihse Bursie wrote: > The proper way to disable warnings is to use the DISABLED_WARNINGS arguments. In this particular case, there was already a pragma but due to incorrect restrictions it did not apply to clang. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24357#pullrequestreview-2733182097 From joehw at openjdk.org Tue Apr 1 16:08:12 2025 From: joehw at openjdk.org (Joe Wang) Date: Tue, 1 Apr 2025 16:08:12 GMT Subject: RFR: 8353234: Refactor XMLSecurityPropertyManager In-Reply-To: References: Message-ID: On Mon, 31 Mar 2025 17:42:20 GMT, Joe Wang wrote: > Refactor XMLSecurityPropertyManager. > The Xerces and Xalan components each had its own XMLSecurityManager and XMLSecurityPropertyManager. In a previous fix, the former had been unified as part of that changeset. This change will allow future changes to handle XMLSecurityManager and XMLSecurityPropertyManager in a similar manner. > > No material change has been made to the classes. The new classes were based on the classes in xalan/utils with a methods merged from that in xerces/utils. Update on test: Tier1 - 3 returned fine with one unrelated failure (SignedJar.java). JCK: does return a failure in a getAttribute test. Will update the PR and add a set/get test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24334#issuecomment-2769873156 From alanb at openjdk.org Tue Apr 1 16:16:13 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 1 Apr 2025 16:16:13 GMT Subject: RFR: 8352689: Allow for hash sum overrides when linking from the run-time image [v2] In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 14:50:11 GMT, Alan Bateman wrote: >>> > The cacerts issue mentioned in the JBS issue relates to an RPM installation of the JDK where the cacerts file is a symlink to the distro provided one. So I think that's "use system" issue. >>> > TZ updates would potentially break this too. If an external tool updates `tzdb.dat` then the hash sum computed at JDK build-time will no longer match. I believe this could also be solved with a sha-override (e.g. by coming from a file `@${java.home}/sha-override.txt`) which would get the update along with `tzdb.dat`. >>> >>> I think one direction to explore is configuring which files or directory are "upgradable". Upgradable modules aren't excluded from the hash computation to allow upgrade via the upgrade module path. Something similar here would allow jlink to report that tzdb.dat has been upgraded. Maybe cacerts is the same but need to look closer as the hash computation shouldn't be following sym links outside of the runtime image. >> >> I'll keep looking into this specific case. However, it sounds a bit orthogonal to the patch at hand which I do believe we still need for the original reasons mentioned (RPM changing binaries after the JDK build is long done and the windows issue of the JDK build itself placing different *.pdb files into the image than was present at jlink time). So perhaps we should explore this in parallel? > >> I'll keep looking into this specific case. However, it sounds a bit orthogonal to the patch at hand which I do believe we still need for the original reasons mentioned (RPM changing binaries after the JDK build is long done and the windows issue of the JDK build itself placing different *.pdb files into the image than was present at jlink time). So perhaps we should explore this in parallel? > > I think upgradable files is something we can deal with. I'm not sure yet on the PDB issue, need to think more about about the scenarios to see what might make sense. > @AlanBateman Any more thoughts on this? We'd need to include a patch like this one for getting the Fedora JDK 24+ builds to work with JEP 493 enabled. Thanks! Allowing for a small number of upgradable files is needed, I see you have a JBS issue for that. I have not warmed to the proposal to have override or have alt hashes, I think we need to think spend more time thinking about the issues there. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24190#issuecomment-2769890734 From smarks at openjdk.org Tue Apr 1 16:20:28 2025 From: smarks at openjdk.org (Stuart Marks) Date: Tue, 1 Apr 2025 16:20:28 GMT Subject: RFR: 8327858: Improve spliterator and forEach for single-element immutable collections [v4] In-Reply-To: References: Message-ID: On Fri, 11 Oct 2024 15:49:33 GMT, Chen Liang wrote: >> Please review this patch that: >> 1. Implemented `forEach` to optimize for 1 or 2 element collections. >> 2. Implemented `spliterator` to optimize for a single element. >> >> The default implementations for multiple-element immutable collections are fine as-is, specializing implementation doesn't provide much benefit. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - s'marks requests > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream > - Add test to ensure reproducible iteration order > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream > - Use the improved form in forEach > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream > - Null checks should probably be in the beginning... > - mark implicit null checks > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream > - ... and 8 more: https://git.openjdk.org/jdk/compare/7276a1be...4f1f4f1b Thanks for sticking with this. Sorry for the delay. Got lost in all the GitHub notifications. ------------- Marked as reviewed by smarks (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15834#pullrequestreview-2733270367 From vklang at openjdk.org Tue Apr 1 16:23:28 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 1 Apr 2025 16:23:28 GMT Subject: RFR: 8327858: Improve spliterator and forEach for single-element immutable collections [v4] In-Reply-To: References: Message-ID: On Fri, 11 Oct 2024 15:49:33 GMT, Chen Liang wrote: >> Please review this patch that: >> 1. Implemented `forEach` to optimize for 1 or 2 element collections. >> 2. Implemented `spliterator` to optimize for a single element. >> >> The default implementations for multiple-element immutable collections are fine as-is, specializing implementation doesn't provide much benefit. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - s'marks requests > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream > - Add test to ensure reproducible iteration order > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream > - Use the improved form in forEach > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream > - Null checks should probably be in the beginning... > - mark implicit null checks > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream > - ... and 8 more: https://git.openjdk.org/jdk/compare/7276a1be...4f1f4f1b Looks worth while, thanks @liach! ------------- Marked as reviewed by vklang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15834#pullrequestreview-2733280984 From naoto at openjdk.org Tue Apr 1 16:26:22 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 1 Apr 2025 16:26:22 GMT Subject: Integrated: 8353118: Deprecate the use of `java.locale.useOldISOCodes` system property In-Reply-To: References: Message-ID: On Fri, 28 Mar 2025 20:17:30 GMT, Naoto Sato wrote: > Proposing to remove the `java.locale.useOldISOCodes` system property. This property is for backward compatibility introduced back in JDK17 and I believe it is now fine to remove it. In this PR targeting JDK25, it emits a deprecate-for-removal warning on startup if the system property is set to true (no behavioral change except the warning). The plan is eventually to remove it after JDK25. A corresponding CSR has been drafted. This pull request has now been integrated. Changeset: 564066d5 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/564066d549cf4ec7608f57ea4910b5813f7353c3 Stats: 23 lines in 3 files changed: 11 ins; 1 del; 11 mod 8353118: Deprecate the use of `java.locale.useOldISOCodes` system property Reviewed-by: iris, jlu ------------- PR: https://git.openjdk.org/jdk/pull/24302 From naoto at openjdk.org Tue Apr 1 16:26:22 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 1 Apr 2025 16:26:22 GMT Subject: RFR: 8353118: Deprecate the use of `java.locale.useOldISOCodes` system property In-Reply-To: References: Message-ID: On Fri, 28 Mar 2025 20:17:30 GMT, Naoto Sato wrote: > Proposing to remove the `java.locale.useOldISOCodes` system property. This property is for backward compatibility introduced back in JDK17 and I believe it is now fine to remove it. In this PR targeting JDK25, it emits a deprecate-for-removal warning on startup if the system property is set to true (no behavioral change except the warning). The plan is eventually to remove it after JDK25. A corresponding CSR has been drafted. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24302#issuecomment-2769911047 From jlu at openjdk.org Tue Apr 1 16:52:19 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 1 Apr 2025 16:52:19 GMT Subject: RFR: 8353322: Specification of ChoiceFormat#parse(String, ParsePosition) is inadequate Message-ID: Please review this PR which specifies the `ChoiceFormat#parse(String, ParsePosition)` method. A corresponding CSR is filed. The current specification is simply "Parses a Number from the input text" which does not indicate how the value is returned. The criteria for a match, as well as no match should be made clear. ------------- Commit messages: - call 2-arg parse in example - init Changes: https://git.openjdk.org/jdk/pull/24361/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24361&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353322 Stats: 20 lines in 1 file changed: 17 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24361.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24361/head:pull/24361 PR: https://git.openjdk.org/jdk/pull/24361 From alanb at openjdk.org Tue Apr 1 16:59:23 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 1 Apr 2025 16:59:23 GMT Subject: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v7] In-Reply-To: References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> Message-ID: On Tue, 1 Apr 2025 07:22:45 GMT, Jaikiran Pai wrote: >> Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`. >> >> The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes. >> >> I'll draft a CSR once we agree on the proposed text. > > 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 14 additional commits since the last revision: > > - Alan's input - replace "@apiNote" in favour of formal spec > - merge latest from master branch > - Lance's inputs > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - additional updates to the doc > - merge latest from master branch > - change "@implSpec" to "@apiNote" and update their text > - add class level documentation > - ... and 4 more: https://git.openjdk.org/jdk/compare/acbfb6c5...f2d08bad src/java.base/share/classes/java/util/zip/DeflaterInputStream.java line 39: > 37: *

Compressor Usage

> 38: * An {@linkplain DeflaterInputStream input stream} that is created without specifying > 39: * a {@linkplain Deflater compressor} will use a default compressor. The default Reading this again makes it wonder if "will use a default compressor" should be adjusted to say "will create a compressor", only to avoid anyone thinking there is a system wide default compressor. src/java.base/share/classes/java/util/zip/DeflaterInputStream.java line 88: > 86: *

> 87: * The default compressor will be closed when this input stream > 88: * is {@linkplain #close() closed}. There is another case where "the default compressor" may be mis-read to mean a system-wide compressor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23655#discussion_r2023231878 PR Review Comment: https://git.openjdk.org/jdk/pull/23655#discussion_r2023234064 From alanb at openjdk.org Tue Apr 1 17:13:21 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 1 Apr 2025 17:13:21 GMT Subject: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v6] In-Reply-To: References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> <7cJ7S9sIDrpnWSLyQRh7kD4myMQNOT89AqUtNCMk48s=.0545e3ce-5db4-4db3-8fe4-949f9ec39e79@github.com> Message-ID: On Tue, 1 Apr 2025 14:50:01 GMT, Chen Liang wrote: >> It's hard for me to guess what prompted that question, but I'll take a guess - are you asking this question to decide whether we should reword the pre-existing javadoc on these constructors to explicitly state that a new decompressor/compressor instance gets created for each instance of the stream? If so, then my opinion is that we shouldn't change that part of the existing doc. >> >> If you meant something else, then please add the details and we can decide if any additional changes are necessary to the text. > > My opinion is that: if it is possible for another implementation to share the backing in/deflator (such as via thread-local instances) that does not always need to be closed when an in/output stream is closed, then we should not specify in a way that rules out such an implementation. The deflater is exposed to subclasses via a protected field so it's part of the API. I think what Jai has is good but I'm nervous about the word "default" as it suggests a global default where as it's a deflater for each output stream. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23655#discussion_r2023286259 From acobbs at openjdk.org Tue Apr 1 17:36:42 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 1 Apr 2025 17:36:42 GMT Subject: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v6] In-Reply-To: References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> <7cJ7S9sIDrpnWSLyQRh7kD4myMQNOT89AqUtNCMk48s=.0545e3ce-5db4-4db3-8fe4-949f9ec39e79@github.com> Message-ID: On Tue, 1 Apr 2025 17:10:08 GMT, Alan Bateman wrote: >> My opinion is that: if it is possible for another implementation to share the backing in/deflator (such as via thread-local instances) that does not always need to be closed when an in/output stream is closed, then we should not specify in a way that rules out such an implementation. > > The deflater is exposed to subclasses via a protected field so it's part of the API. I think what Jai has is good but I'm nervous about the word "default" as it suggests a global default where as it's a deflater for each output stream. What about something like this? _An output stream that is created without specifying a decompressor takes responsibility for providing and managing a decompressor, including ensuring that it is properly closed after the output stream is closed. If a decompressor is specified when creating the output stream, the caller takes responsibility for managing that decompressor, including ensuring that it is properly closed after the output stream is closed._ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23655#discussion_r2023373942 From naoto at openjdk.org Tue Apr 1 18:22:15 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 1 Apr 2025 18:22:15 GMT Subject: RFR: 8353322: Specification of ChoiceFormat#parse(String, ParsePosition) is inadequate In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 16:45:26 GMT, Justin Lu wrote: > Please review this PR which specifies the `ChoiceFormat#parse(String, ParsePosition)` method. A corresponding CSR is filed. The current specification is simply "Parses a Number from the input text" which does not indicate how the value is returned. The criteria for a match, as well as no match should be made clear. src/java.base/share/classes/java/text/ChoiceFormat.java line 571: > 569: * {@snippet lang=java : > 570: * var fmt = new ChoiceFormat("0#foo|1#bar|2#baz"); > 571: * fmt.parse("baz", new ParsePosition(0)); // returns 2 This returns `2.0`? src/java.base/share/classes/java/text/ChoiceFormat.java line 576: > 574: * > 575: * @implNote The {@code Number} subtype returned by the JDK reference > 576: * implementation of this method is always {@code Double}. Do we need to use `@implNote` here? Since choices are `double`s (as in the class description), I think we can safely say this returns a `Double` as in normative text. If some implementation returns an `Integer`, I think it is a bug. Returning a `Double.NaN` for no-match may be considered implNote though (one might throw an exception). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24361#discussion_r2023404649 PR Review Comment: https://git.openjdk.org/jdk/pull/24361#discussion_r2023462230 From asemenyuk at openjdk.org Tue Apr 1 19:00:56 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 1 Apr 2025 19:00:56 GMT Subject: RFR: 8352419: Test tools/jpackage/share/ErrorTest.java#id0 and #id1 fail [v2] In-Reply-To: <1QksvVOulgv5y1TaYzDy8SomeWoYrGp0WgOU4GhLpwk=.ae5739b3-4ca0-462b-b4d7-4e0d8480572f@github.com> References: <1QksvVOulgv5y1TaYzDy8SomeWoYrGp0WgOU4GhLpwk=.ae5739b3-4ca0-462b-b4d7-4e0d8480572f@github.com> Message-ID: <4VAUOiGy-CZ8bcltzuA6RG-gx0uwZ5dTxU6b8FrThI0=.854b5ce8-6d6b-470a-83af-56e57259ef97@github.com> > Make tools/jpackage/share/ErrorTest.java test safely handle the case when native bundling is unavailable on the test host. > > Additionally: > - If native bundling is unavailable on the test host, PackageTest will throw `jtreg.SkippedException` and mark the test as skipped instead of silently doing nothing. This should mark a few jpackage tests "skipped" in tests runs on Alpine Linux that doesn't support either .deb or .rpm packaging. > - Get rid of the dependency on `jtreg.SkippedException` from `/jdk/test` lib as this exception can be thrown from almost every jpackage test because of the changes in PackageTest. Instead embed `jtreg.SkippedException` classfile in TKit.java source and load it from there. This is a less intrusive alternative to adding > > * @library /test/lib > * @build jtreg.SkippedException > > in every jtreg test declaration Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into JDK-8352419 - Fix failure in PackageTestTest when native packaging is not available - bash ./bin/blessed-modifier-order.sh test/jdk/tools/jpackage/ - 8352419: Test tools/jpackage/share/ErrorTest.java#id0 and #id1 fail - Add PackageType.throwSkippedExceptionIfNativePackagingUnavailable(). Stable order of platform package types. Make PackageTest fail if native packagers are unavailable. - Get rid of dependency on "/test/lib" tets lib ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24294/files - new: https://git.openjdk.org/jdk/pull/24294/files/353e3f36..e748f993 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24294&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24294&range=00-01 Stats: 12214 lines in 210 files changed: 8161 ins; 3198 del; 855 mod Patch: https://git.openjdk.org/jdk/pull/24294.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24294/head:pull/24294 PR: https://git.openjdk.org/jdk/pull/24294 From asemenyuk at openjdk.org Tue Apr 1 19:02:55 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 1 Apr 2025 19:02:55 GMT Subject: RFR: 8352419: Test tools/jpackage/share/ErrorTest.java#id0 and #id1 fail In-Reply-To: References: <1QksvVOulgv5y1TaYzDy8SomeWoYrGp0WgOU4GhLpwk=.ae5739b3-4ca0-462b-b4d7-4e0d8480572f@github.com> Message-ID: <2amWSZzesJiR5fDfX7pRktKd55AtOs_CO4rgV1mFF2U=.7b864476-20db-4199-9412-d9d2d7797d1b@github.com> On Tue, 1 Apr 2025 14:20:17 GMT, Arno Zeller wrote: >> Make tools/jpackage/share/ErrorTest.java test safely handle the case when native bundling is unavailable on the test host. >> >> Additionally: >> - If native bundling is unavailable on the test host, PackageTest will throw `jtreg.SkippedException` and mark the test as skipped instead of silently doing nothing. This should mark a few jpackage tests "skipped" in tests runs on Alpine Linux that doesn't support either .deb or .rpm packaging. >> - Get rid of the dependency on `jtreg.SkippedException` from `/jdk/test` lib as this exception can be thrown from almost every jpackage test because of the changes in PackageTest. Instead embed `jtreg.SkippedException` classfile in TKit.java source and load it from there. This is a less intrusive alternative to adding >> >> * @library /test/lib >> * @build jtreg.SkippedException >> >> in every jtreg test declaration > > The same issue can be seen on a Windows system without WIX installed. @ArnoZeller, I've fixed the issue with PackageTestTest.java and verified that all jpackage tests pass on Windows without installed WiX. Please try again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24294#issuecomment-2770418748 From jlu at openjdk.org Tue Apr 1 19:04:25 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 1 Apr 2025 19:04:25 GMT Subject: RFR: 8353322: Specification of ChoiceFormat#parse(String, ParsePosition) is inadequate [v2] In-Reply-To: References: Message-ID: > Please review this PR which specifies the `ChoiceFormat#parse(String, ParsePosition)` method. A corresponding CSR is filed. The current specification is simply "Parses a Number from the input text" which does not indicate how the value is returned. The criteria for a match, as well as no match should be made clear. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: reflect Naoto's review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24361/files - new: https://git.openjdk.org/jdk/pull/24361/files/faaa9b9c..24d57bb2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24361&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24361&range=00-01 Stats: 10 lines in 1 file changed: 0 ins; 3 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/24361.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24361/head:pull/24361 PR: https://git.openjdk.org/jdk/pull/24361 From jlu at openjdk.org Tue Apr 1 19:04:25 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 1 Apr 2025 19:04:25 GMT Subject: RFR: 8353322: Specification of ChoiceFormat#parse(String, ParsePosition) is inadequate [v2] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 18:17:12 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> reflect Naoto's review > > src/java.base/share/classes/java/text/ChoiceFormat.java line 576: > >> 574: * >> 575: * @implNote The {@code Number} subtype returned by the JDK reference >> 576: * implementation of this method is always {@code Double}. > > Do we need to use `@implNote` here? Since choices are `double`s (as in the class description), I think we can safely say this returns a `Double` as in normative text. If some implementation returns an `Integer`, I think it is a bug. Returning a `Double.NaN` for no-match may be considered implNote though (one might throw an exception). I was either way on the `implNote`, since I thought an implementation could decide to normalize a double limit to an integral type. However that's probably unlikely and I agree the wording can be fine as normative since ChoiceFormat is composed of doubles. I think it's best to make returning Double.NaN normative (i.e. not allow flexibility for throwing an exception). The `NumberFormat.parse(String, ParsePosition)` methods return a failure value instead of throwing like `parse(String)` does. (E.g. DecimalFormat returns null on failed parse for 2 arg parse.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24361#discussion_r2023523992 From asemenyuk at openjdk.org Tue Apr 1 19:25:34 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 1 Apr 2025 19:25:34 GMT Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables available in *.cfg files [v4] In-Reply-To: References: Message-ID: > jpackage app laucnher will expand environment variables in .cfg files. > > Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and `$ROOTDIR` tokens with the corresponding path values. With this patch, any environment variable can be expanded. The syntax is shell-like `$ENV_VAR_NAME` or `${ENV_VAR_NAME}`. If `$ENV_VAR_NAME` syntax is used, the variable name stops at the first character outside of `[a-zA-Z0-9_]` character range. If `${ENV_VAR_NAME}` syntax is used, the variable name stops at the first `}` character after `${` substring. E.g: > | String | Variables | Variable Values | Expanded String | Note | > | -------- | ------- |------- |------- |------- | > | 

Welcome $USER!
| 
USER
| 
USER=John
| 
Welcome John!
|| > | 
Welcome $USER!
| 
USER
| 
not set
| 
Welcome $USER!
| Unset variables are not expanded. | > | 
Welcome $USER2
| 
USER2
| 
USER2=John
| 
Welcome John!
|| > | 
Welcome ${USER}2!
| 
USER
| 
USER=John
| 
Welcome John2!
|| > | 
Welcome $USER-2!
| 
USER
| 
USER=John
| 
Welcome John-2!
|| > | 
Welcome ${USER-2}!
| 
USER-2
| 
USER-2=John
| 
Welcome John!
| `USER-2` is likely to be an invalid env variable name, but jpackage launcher is not validating names. | > > `$` character combination prevents variable expansion: > | String | Variables | Variable Values | Expanded String | > | -------- | ------- |------- |------- | > | 
Hello \$A! Bye $B
| B | 
B=John
| 
Hello $A! Bye John
| > | 
Hello \${A}! Bye $B
| B | 
B=John
| 
Hello ${A}! Bye John
| > > `\` character combination escapes ``: > | String | Variables | Variable Values | Expanded String | > | -------- | ------- |------- |------- | > | 
Hello \\\$A! Bye $B
| A, B | 
A=Ana
B=John
| 
Hello \\Ana! Bye John
| > > If `` character is not followed by another `` character or `$` character, it is interpreted as a regular character: > | String | Expanded string | > | -------- | ------- | > |
a\\b\\c
|
a\\b\\c
| > > > Expansion is non-recursive: > | String | Variables | Variable Values | Expanded String | Note | > | -------- | ------- |------- |------- |------- | > | 
Hello $A!
| A | 
A=$B
B=John
| 
Hello $B
| Variable "B" wi... Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Merge branch 'master' into JDK-8341641-master - Merge branch 'JDK-8341641-master' of https://github.com/alexeysemenyukoracle/jdk into JDK-8341641-master - Update src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/TokenReplace.java Co-authored-by: Andrey Turbanov - Formatting fixed - Shorter test desc - Minor - A bit of javadoc - Update copyright year - Applied bin/blessed-modifier-order.sh - 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables available in *.cfg files - ... and 3 more: https://git.openjdk.org/jdk/compare/6a46d554...a4920a0a ------------- Changes: https://git.openjdk.org/jdk/pull/23923/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23923&range=03 Stats: 557 lines in 9 files changed: 512 ins; 9 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/23923.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23923/head:pull/23923 PR: https://git.openjdk.org/jdk/pull/23923 From naoto at openjdk.org Tue Apr 1 19:42:20 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 1 Apr 2025 19:42:20 GMT Subject: RFR: 8353322: Specification of ChoiceFormat#parse(String, ParsePosition) is inadequate [v2] In-Reply-To: References: Message-ID: <_wstnNEYpUPVZk5cU_nvJjetseFzPNBAJLohGEAawGA=.965b06ff-d215-440c-b3bd-489244947550@github.com> On Tue, 1 Apr 2025 19:04:25 GMT, Justin Lu wrote: >> Please review this PR which specifies the `ChoiceFormat#parse(String, ParsePosition)` method. A corresponding CSR is filed. The current specification is simply "Parses a Number from the input text" which does not indicate how the value is returned. The criteria for a match, as well as no match should be made clear. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect Naoto's review I am OK with returning `Double.NaN` as normative. I believe the risk is quite low, and it would be only a conformance issue (no practical problem will arise) src/java.base/share/classes/java/text/ChoiceFormat.java line 564: > 562: * {@code Double}. The value returned is the {@code limit} corresponding > 563: * to the {@code format} that is the longest substring of the input text. > 564: * Matching is done in ascending order, when multiple {@code formats} match Nit: {@code format}s src/java.base/share/classes/java/text/ChoiceFormat.java line 584: > 582: * first index of the character that caused the parse to fail. > 583: * @return A Number which represents the {@code limit} corresponding to the {@code > 584: * format} parsed. We could clarify the no match case with `Double.NaN` here too ------------- PR Review: https://git.openjdk.org/jdk/pull/24361#pullrequestreview-2733870693 PR Review Comment: https://git.openjdk.org/jdk/pull/24361#discussion_r2023570395 PR Review Comment: https://git.openjdk.org/jdk/pull/24361#discussion_r2023571566 From matsaave at openjdk.org Tue Apr 1 19:51:29 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Tue, 1 Apr 2025 19:51:29 GMT Subject: RFR: 8352437: Support --add-exports with -XX:+AOTClassLinking [v3] In-Reply-To: References: Message-ID: <8u8iBz0SurEb2I01k0OxYN11YgY_1b-RJP9Xu2aw1ss=.9ef1958c-00b1-4290-9dc7-af9ab1b3d6c8@github.com> On Thu, 27 Mar 2025 22:13:02 GMT, Ioi Lam wrote: >> `-XX:+AOTClassLinking` requires the CDS archived full module graph (FMG). >> >> - Before this PR, when `--add-export` is specified, FMG is disabled, so AOT caches created with `-XX:+AOTClassLinking` cannot be loaded. >> - After this PR, if the exact same `--add-export` flags as specified across the training/assembly/production phases, the FMG can be used, so we can use so AOT caches created with `-XX:+AOTClassLinking`. >> >> The change itself is straight-forward: just remember the `--add-export` flags specified during AOT cache creation, and check the exact same ones are used during the production run. >> >> I did a fair amount of refactoring to change the "exact options specified" checks in modules.cpp, so more such options can be easily added in the future (we need to handle `--add-reads` and `--add-opens` in future RFEs). >> >> (Note: this PR depends on #24122 ) > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - @calvinccheung comments > - Merge branch 'master' into 8352437-aot-class-linking-incompatible-with-add-exports > - Fixed whitespaces > - clean up > - 8352437: -XX:+AOTClassLinking is not compatible with --add-export > - added comments > - added comments > - Prototype: support --add-exports in CDS FMG Changes and cleanup look good! Thanks! ------------- Marked as reviewed by matsaave (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24124#pullrequestreview-2733895429 From cjplummer at openjdk.org Tue Apr 1 20:00:22 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 1 Apr 2025 20:00:22 GMT Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups() can lock up target VM [v7] In-Reply-To: References: Message-ID: > Calling ThreadGroupReference.groups() from an event handler can cause a deadlock. Details in first comment. Tested with :jdk_lang on all supported platforms and tier1, tier2, tier3, and tier5 svc testing. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: minor comment update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24236/files - new: https://git.openjdk.org/jdk/pull/24236/files/977ecf15..80f75c60 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24236&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24236&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24236.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24236/head:pull/24236 PR: https://git.openjdk.org/jdk/pull/24236 From jlu at openjdk.org Tue Apr 1 20:32:45 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 1 Apr 2025 20:32:45 GMT Subject: RFR: 8353322: Specification of ChoiceFormat#parse(String, ParsePosition) is inadequate [v3] In-Reply-To: References: Message-ID: > Please review this PR which specifies the `ChoiceFormat#parse(String, ParsePosition)` method. A corresponding CSR is filed. The current specification is simply "Parses a Number from the input text" which does not indicate how the value is returned. The criteria for a match, as well as no match should be made clear. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Address further comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24361/files - new: https://git.openjdk.org/jdk/pull/24361/files/24d57bb2..d3864418 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24361&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24361&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24361.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24361/head:pull/24361 PR: https://git.openjdk.org/jdk/pull/24361 From sspitsyn at openjdk.org Tue Apr 1 20:36:25 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 1 Apr 2025 20:36:25 GMT Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups() can lock up target VM [v7] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 20:00:22 GMT, Chris Plummer wrote: >> Calling ThreadGroupReference.groups() from an event handler can cause a deadlock. Details in first comment. Tested with :jdk_lang on all supported platforms and tier1, tier2, tier3, and tier5 svc testing. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > minor comment update Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24236#pullrequestreview-2733985461 From jlu at openjdk.org Tue Apr 1 20:37:07 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 1 Apr 2025 20:37:07 GMT Subject: RFR: 8353322: Specification of ChoiceFormat#parse(String, ParsePosition) is inadequate [v2] In-Reply-To: <_wstnNEYpUPVZk5cU_nvJjetseFzPNBAJLohGEAawGA=.965b06ff-d215-440c-b3bd-489244947550@github.com> References: <_wstnNEYpUPVZk5cU_nvJjetseFzPNBAJLohGEAawGA=.965b06ff-d215-440c-b3bd-489244947550@github.com> Message-ID: On Tue, 1 Apr 2025 19:36:04 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> reflect Naoto's review > > src/java.base/share/classes/java/text/ChoiceFormat.java line 564: > >> 562: * {@code Double}. The value returned is the {@code limit} corresponding >> 563: * to the {@code format} that is the longest substring of the input text. >> 564: * Matching is done in ascending order, when multiple {@code formats} match > > Nit: {@code format}s Sounds good. Addressed the conformance issue possibility in the CSR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24361#discussion_r2023639927 From asemenyuk at openjdk.org Tue Apr 1 20:57:48 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 1 Apr 2025 20:57:48 GMT Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables available in *.cfg files [v5] In-Reply-To: References: Message-ID: > jpackage app laucnher will expand environment variables in .cfg files. > > Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and `$ROOTDIR` tokens with the corresponding path values. With this patch, any environment variable can be expanded. The syntax is shell-like `$ENV_VAR_NAME` or `${ENV_VAR_NAME}`. If `$ENV_VAR_NAME` syntax is used, the variable name stops at the first character outside of `[a-zA-Z0-9_]` character range. If `${ENV_VAR_NAME}` syntax is used, the variable name stops at the first `}` character after `${` substring. E.g: > | String | Variables | Variable Values | Expanded String | Note | > | -------- | ------- |------- |------- |------- | > | 
Welcome $USER!
| 
USER
| 
USER=John
| 
Welcome John!
|| > | 
Welcome $USER!
| 
USER
| 
not set
| 
Welcome $USER!
| Unset variables are not expanded. | > | 
Welcome $USER2
| 
USER2
| 
USER2=John
| 
Welcome John!
|| > | 
Welcome ${USER}2!
| 
USER
| 
USER=John
| 
Welcome John2!
|| > | 
Welcome $USER-2!
| 
USER
| 
USER=John
| 
Welcome John-2!
|| > | 
Welcome ${USER-2}!
| 
USER-2
| 
USER-2=John
| 
Welcome John!
| `USER-2` is likely to be an invalid env variable name, but jpackage launcher is not validating names. | > > `$` character combination prevents variable expansion: > | String | Variables | Variable Values | Expanded String | > | -------- | ------- |------- |------- | > | 
Hello \$A! Bye $B
| B | 
B=John
| 
Hello $A! Bye John
| > | 
Hello \${A}! Bye $B
| B | 
B=John
| 
Hello ${A}! Bye John
| > > `\` character combination escapes ``: > | String | Variables | Variable Values | Expanded String | > | -------- | ------- |------- |------- | > | 
Hello \\\$A! Bye $B
| A, B | 
A=Ana
B=John
| 
Hello \\Ana! Bye John
| > > If `` character is not followed by another `` character or `$` character, it is interpreted as a regular character: > | String | Expanded string | > | -------- | ------- | > |
a\\b\\c
|
a\\b\\c
| > > > Expansion is non-recursive: > | String | Variables | Variable Values | Expanded String | Note | > | -------- | ------- |------- |------- |------- | > | 
Hello $A!
| A | 
A=$B
B=John
| 
Hello $B
| Variable "B" wi... Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Update help ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23923/files - new: https://git.openjdk.org/jdk/pull/23923/files/a4920a0a..f9dbf5d2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23923&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23923&range=03-04 Stats: 23 lines in 1 file changed: 23 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23923.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23923/head:pull/23923 PR: https://git.openjdk.org/jdk/pull/23923 From asemenyuk at openjdk.org Tue Apr 1 21:04:51 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 1 Apr 2025 21:04:51 GMT Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables available in *.cfg files [v6] In-Reply-To: References: Message-ID: > jpackage app laucnher will expand environment variables in .cfg files. > > Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and `$ROOTDIR` tokens with the corresponding path values. With this patch, any environment variable can be expanded. The syntax is shell-like `$ENV_VAR_NAME` or `${ENV_VAR_NAME}`. If `$ENV_VAR_NAME` syntax is used, the variable name stops at the first character outside of `[a-zA-Z0-9_]` character range. If `${ENV_VAR_NAME}` syntax is used, the variable name stops at the first `}` character after `${` substring. E.g: > | String | Variables | Variable Values | Expanded String | Note | > | -------- | ------- |------- |------- |------- | > | 
Welcome $USER!
| 
USER
| 
USER=John
| 
Welcome John!
|| > | 
Welcome $USER!
| 
USER
| 
not set
| 
Welcome $USER!
| Unset variables are not expanded. | > | 
Welcome $USER2
| 
USER2
| 
USER2=John
| 
Welcome John!
|| > | 
Welcome ${USER}2!
| 
USER
| 
USER=John
| 
Welcome John2!
|| > | 
Welcome $USER-2!
| 
USER
| 
USER=John
| 
Welcome John-2!
|| > | 
Welcome ${USER-2}!
| 
USER-2
| 
USER-2=John
| 
Welcome John!
| `USER-2` is likely to be an invalid env variable name, but jpackage launcher is not validating names. | > > `$` character combination prevents variable expansion: > | String | Variables | Variable Values | Expanded String | > | -------- | ------- |------- |------- | > | 
Hello \$A! Bye $B
| B | 
B=John
| 
Hello $A! Bye John
| > | 
Hello \${A}! Bye $B
| B | 
B=John
| 
Hello ${A}! Bye John
| > > `\` character combination escapes ``: > | String | Variables | Variable Values | Expanded String | > | -------- | ------- |------- |------- | > | 
Hello \\\$A! Bye $B
| A, B | 
A=Ana
B=John
| 
Hello \\Ana! Bye John
| > > If `` character is not followed by another `` character or `$` character, it is interpreted as a regular character: > | String | Expanded string | > | -------- | ------- | > |
a\\b\\c
|
a\\b\\c
| > > > Expansion is non-recursive: > | String | Variables | Variable Values | Expanded String | Note | > | -------- | ------- |------- |------- |------- | > | 
Hello $A!
| A | 
A=$B
B=John
| 
Hello $B
| Variable "B" wi... Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Better wording ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23923/files - new: https://git.openjdk.org/jdk/pull/23923/files/f9dbf5d2..5d2599d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23923&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23923&range=04-05 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/23923.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23923/head:pull/23923 PR: https://git.openjdk.org/jdk/pull/23923 From ihse at openjdk.org Tue Apr 1 21:12:14 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 1 Apr 2025 21:12:14 GMT Subject: RFR: 8304674: File java.c compile error with -fsanitize=address -O0 [v3] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 12:07:09 GMT, SendaoYan wrote: >> Hi all, >> File src/java.base/share/native/libjli/java.c compile error: control reaches end of non-void function [-Werror=return-type] with gcc options -fsanitize=address -O0. The function int JavaMain(void* _args) in this file will execute return ret in LEAVE() macro, but gcc with -O0 is not smart enough to recognized that the function already has return statement before at the end of function. It's a gcc bug which has been recorded by [80959](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80959), and below code snippet can demonstrate the gcc bug. I think we should disable return-type gcc warning for java.c file before the gcc bug has been fixed. Risk is low. >> >> >>> cat java.c >> char a() { >> return 0; >> int b; >> if (a(&b)) >> return 0; >> } >> >>> gcc -O0 -Wall -Wextra -Werror -O0 -c java.c -fsanitize=address >> java.c: In function ?a?: >> java.c:6:1: error: control reaches end of non-void function [-Werror=return-type] >> 6 | } >> | ^ >> cc1: all warnings being treated as errors > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > add "#if defined(__GNUC__)" to fix windows build warning LGTM. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24318#pullrequestreview-2734052946 From asemenyuk at openjdk.org Tue Apr 1 21:17:03 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 1 Apr 2025 21:17:03 GMT Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables available in *.cfg files [v7] In-Reply-To: References: Message-ID: <3VLxHbPfGxTH27H_J1iW0MCCaFLxaTxlysNpM_nSGng=.10569022-0d94-40dc-bfa3-7f39f973245f@github.com> > jpackage app laucnher will expand environment variables in .cfg files. > > Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and `$ROOTDIR` tokens with the corresponding path values. With this patch, any environment variable can be expanded. The syntax is shell-like `$ENV_VAR_NAME` or `${ENV_VAR_NAME}`. If `$ENV_VAR_NAME` syntax is used, the variable name stops at the first character outside of `[a-zA-Z0-9_]` character range. If `${ENV_VAR_NAME}` syntax is used, the variable name stops at the first `}` character after `${` substring. E.g: > | String | Variables | Variable Values | Expanded String | Note | > | -------- | ------- |------- |------- |------- | > | 
Welcome $USER!
| 
USER
| 
USER=John
| 
Welcome John!
|| > | 
Welcome $USER!
| 
USER
| 
not set
| 
Welcome $USER!
| Unset variables are not expanded. | > | 
Welcome $USER2
| 
USER2
| 
USER2=John
| 
Welcome John!
|| > | 
Welcome ${USER}2!
| 
USER
| 
USER=John
| 
Welcome John2!
|| > | 
Welcome $USER-2!
| 
USER
| 
USER=John
| 
Welcome John-2!
|| > | 
Welcome ${USER-2}!
| 
USER-2
| 
USER-2=John
| 
Welcome John!
| `USER-2` is likely to be an invalid env variable name, but jpackage launcher is not validating names. | > > `$` character combination prevents variable expansion: > | String | Variables | Variable Values | Expanded String | > | -------- | ------- |------- |------- | > | 
Hello \$A! Bye $B
| B | 
B=John
| 
Hello $A! Bye John
| > | 
Hello \${A}! Bye $B
| B | 
B=John
| 
Hello ${A}! Bye John
| > > `\` character combination escapes ``: > | String | Variables | Variable Values | Expanded String | > | -------- | ------- |------- |------- | > | 
Hello \\\$A! Bye $B
| A, B | 
A=Ana
B=John
| 
Hello \\Ana! Bye John
| > > If `` character is not followed by another `` character or `$` character, it is interpreted as a regular character: > | String | Expanded string | > | -------- | ------- | > |
a\\b\\c
|
a\\b\\c
| > > > Expansion is non-recursive: > | String | Variables | Variable Values | Expanded String | Note | > | -------- | ------- |------- |------- |------- | > | 
Hello $A!
| A | 
A=$B
B=John
| 
Hello $B
| Variable "B" wi... Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Better wording ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23923/files - new: https://git.openjdk.org/jdk/pull/23923/files/5d2599d3..13523ee3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23923&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23923&range=05-06 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23923.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23923/head:pull/23923 PR: https://git.openjdk.org/jdk/pull/23923 From asemenyuk at openjdk.org Tue Apr 1 21:20:54 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 1 Apr 2025 21:20:54 GMT Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables available in *.cfg files [v8] In-Reply-To: References: Message-ID: > jpackage app laucnher will expand environment variables in .cfg files. > > Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and `$ROOTDIR` tokens with the corresponding path values. With this patch, any environment variable can be expanded. The syntax is shell-like `$ENV_VAR_NAME` or `${ENV_VAR_NAME}`. If `$ENV_VAR_NAME` syntax is used, the variable name stops at the first character outside of `[a-zA-Z0-9_]` character range. If `${ENV_VAR_NAME}` syntax is used, the variable name stops at the first `}` character after `${` substring. E.g: > | String | Variables | Variable Values | Expanded String | Note | > | -------- | ------- |------- |------- |------- | > | 
Welcome $USER!
| 
USER
| 
USER=John
| 
Welcome John!
|| > | 
Welcome $USER!
| 
USER
| 
not set
| 
Welcome $USER!
| Unset variables are not expanded. | > | 
Welcome $USER2
| 
USER2
| 
USER2=John
| 
Welcome John!
|| > | 
Welcome ${USER}2!
| 
USER
| 
USER=John
| 
Welcome John2!
|| > | 
Welcome $USER-2!
| 
USER
| 
USER=John
| 
Welcome John-2!
|| > | 
Welcome ${USER-2}!
| 
USER-2
| 
USER-2=John
| 
Welcome John!
| `USER-2` is likely to be an invalid env variable name, but jpackage launcher is not validating names. | > > `$` character combination prevents variable expansion: > | String | Variables | Variable Values | Expanded String | > | -------- | ------- |------- |------- | > | 
Hello \$A! Bye $B
| B | 
B=John
| 
Hello $A! Bye John
| > | 
Hello \${A}! Bye $B
| B | 
B=John
| 
Hello ${A}! Bye John
| > > `\` character combination escapes ``: > | String | Variables | Variable Values | Expanded String | > | -------- | ------- |------- |------- | > | 
Hello \\\$A! Bye $B
| A, B | 
A=Ana
B=John
| 
Hello \\Ana! Bye John
| > > If `` character is not followed by another `` character or `$` character, it is interpreted as a regular character: > | String | Expanded string | > | -------- | ------- | > |
a\\b\\c
|
a\\b\\c
| > > > Expansion is non-recursive: > | String | Variables | Variable Values | Expanded String | Note | > | -------- | ------- |------- |------- |------- | > | 
Hello $A!
| A | 
A=$B
B=John
| 
Hello $B
| Variable "B" wi... Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Minor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23923/files - new: https://git.openjdk.org/jdk/pull/23923/files/13523ee3..2697acd4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23923&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23923&range=06-07 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23923.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23923/head:pull/23923 PR: https://git.openjdk.org/jdk/pull/23923 From darcy at openjdk.org Tue Apr 1 21:44:16 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 1 Apr 2025 21:44:16 GMT Subject: RFR: 8350704: Create tests to ensure the failure behavior of core reflection APIs [v3] In-Reply-To: References: Message-ID: On Mon, 24 Mar 2025 21:29:29 GMT, Chen Liang wrote: >> Core reflection's generic signature parsing system is used for many aspects, including annotations and enclosing methods, yet it is under-tested. It is better for us to set up tests to ensure that sensitive error behaviors of core reflection remain the same across implementation updates, such as #19281. >> >> This patch also includes a JUnit converted version of https://github.com/openjdk/jdk/pull/22581#issuecomment-2521703511 test checking behavior around annotations with duplicate interfaces. Interesting that this causes failure in class, field, and methods (constructors), but not in parameters. >> >> Testing: jdk-tier 1, jdk-tier 2 > > 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: > > - Forgot to commit the updated tests > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/reflect-behavior-tests > - Remove useless directive > - 8350704: Create tests to ensure the failure behavior of core reflection APIs Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23788#pullrequestreview-2734106235 From bchristi at openjdk.org Tue Apr 1 22:04:09 2025 From: bchristi at openjdk.org (Brent Christian) Date: Tue, 1 Apr 2025 22:04:09 GMT Subject: RFR: 8352565: Add native method implementation of Reference.get() [v2] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 09:43:28 GMT, Kim Barrett wrote: >> Please review this change which adds a native method providing the >> implementation of Reference::get. Referece::get is an intrinsic candidate, so >> this native method implementation is only used when the intrinsic is not. >> >> Currently there is intrinsic support by the interpreter, C1, C2, and graal, >> which are always used. With this change we can later remove all the >> per-platform interpreter intrinsic implementations, and might also remove the >> C1 intrinsic implementation. >> >> Testing: >> (1) mach5 tier1-6 normal (so using all the existing intrinsics). >> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled. > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > parameterized return type of native get0 test/hotspot/jtreg/gc/TestNativeReferenceGet.java line 162: > 160: System.out.println("Testing nonconcurrent GC"); > 161: clearReferents(); > 162: strengthenReferents(); Might the GC clear refs between `clearReferents()` and `strengthenReferents()`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2023735808 From almatvee at openjdk.org Tue Apr 1 22:10:19 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 1 Apr 2025 22:10:19 GMT Subject: RFR: 8352419: Test tools/jpackage/share/ErrorTest.java#id0 and #id1 fail [v2] In-Reply-To: <4VAUOiGy-CZ8bcltzuA6RG-gx0uwZ5dTxU6b8FrThI0=.854b5ce8-6d6b-470a-83af-56e57259ef97@github.com> References: <1QksvVOulgv5y1TaYzDy8SomeWoYrGp0WgOU4GhLpwk=.ae5739b3-4ca0-462b-b4d7-4e0d8480572f@github.com> <4VAUOiGy-CZ8bcltzuA6RG-gx0uwZ5dTxU6b8FrThI0=.854b5ce8-6d6b-470a-83af-56e57259ef97@github.com> Message-ID: On Tue, 1 Apr 2025 19:00:56 GMT, Alexey Semenyuk wrote: >> Make tools/jpackage/share/ErrorTest.java test safely handle the case when native bundling is unavailable on the test host. >> >> Additionally: >> - If native bundling is unavailable on the test host, PackageTest will throw `jtreg.SkippedException` and mark the test as skipped instead of silently doing nothing. This should mark a few jpackage tests "skipped" in tests runs on Alpine Linux that doesn't support either .deb or .rpm packaging. >> - Get rid of the dependency on `jtreg.SkippedException` from `/jdk/test` lib as this exception can be thrown from almost every jpackage test because of the changes in PackageTest. Instead embed `jtreg.SkippedException` classfile in TKit.java source and load it from there. This is a less intrusive alternative to adding >> >> * @library /test/lib >> * @build jtreg.SkippedException >> >> in every jtreg test declaration > > Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'master' into JDK-8352419 > - Fix failure in PackageTestTest when native packaging is not available > - bash ./bin/blessed-modifier-order.sh test/jdk/tools/jpackage/ > - 8352419: Test tools/jpackage/share/ErrorTest.java#id0 and #id1 fail > - Add PackageType.throwSkippedExceptionIfNativePackagingUnavailable(). Stable order of platform package types. Make PackageTest fail if native packagers are unavailable. > - Get rid of dependency on "/test/lib" tets lib Latest commit looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24294#pullrequestreview-2734147109 From naoto at openjdk.org Tue Apr 1 22:56:12 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 1 Apr 2025 22:56:12 GMT Subject: RFR: 8353322: Specification of ChoiceFormat#parse(String, ParsePosition) is inadequate [v3] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 20:32:45 GMT, Justin Lu wrote: >> Please review this PR which specifies the `ChoiceFormat#parse(String, ParsePosition)` method. A corresponding CSR is filed. The current specification is simply "Parses a Number from the input text" which does not indicate how the value is returned. The criteria for a match, as well as no match should be made clear. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Address further comments LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24361#pullrequestreview-2734200809 From jpai at openjdk.org Wed Apr 2 01:40:31 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 2 Apr 2025 01:40:31 GMT Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups() can lock up target VM [v7] In-Reply-To: References: Message-ID: <5kETU88L5YqVVQgMSB7QDo8heC9-R4Ia_JhXt2ZkfVQ=.2ce9a39e-ad21-433d-b724-de1ceb3336f5@github.com> On Tue, 1 Apr 2025 20:00:22 GMT, Chris Plummer wrote: >> Calling ThreadGroupReference.groups() from an event handler can cause a deadlock. Details in first comment. Tested with :jdk_lang on all supported platforms and tier1, tier2, tier3, and tier5 svc testing. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > minor comment update Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24236#pullrequestreview-2734354863 From iklam at openjdk.org Wed Apr 2 01:40:39 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 2 Apr 2025 01:40:39 GMT Subject: RFR: 8352437: Support --add-exports with -XX:+AOTClassLinking [v2] In-Reply-To: References: Message-ID: <8-mYgx6Rbq09iYzRPnATDTUTGgVuL98ATMsQCqAeW-4=.d900b7ae-0fdd-4432-84f9-748b0eeb825d@github.com> On Tue, 25 Mar 2025 04:15:11 GMT, Calvin Cheung wrote: >> Ioi Lam 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. > > Code changes look clean. I just have two minor comments on the tests. Thanks @calvinccheung and @matias9927 for the review Passed tiers1-4 and build-tiers5. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24124#issuecomment-2771040013 From iklam at openjdk.org Wed Apr 2 01:40:40 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 2 Apr 2025 01:40:40 GMT Subject: Integrated: 8352437: Support --add-exports with -XX:+AOTClassLinking In-Reply-To: References: Message-ID: On Thu, 20 Mar 2025 04:46:21 GMT, Ioi Lam wrote: > `-XX:+AOTClassLinking` requires the CDS archived full module graph (FMG). > > - Before this PR, when `--add-export` is specified, FMG is disabled, so AOT caches created with `-XX:+AOTClassLinking` cannot be loaded. > - After this PR, if the exact same `--add-export` flags as specified across the training/assembly/production phases, the FMG can be used, so we can use so AOT caches created with `-XX:+AOTClassLinking`. > > The change itself is straight-forward: just remember the `--add-export` flags specified during AOT cache creation, and check the exact same ones are used during the production run. > > I did a fair amount of refactoring to change the "exact options specified" checks in modules.cpp, so more such options can be easily added in the future (we need to handle `--add-reads` and `--add-opens` in future RFEs). > > (Note: this PR depends on #24122 ) This pull request has now been integrated. Changeset: 096e70de Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/096e70de2d3009040d7ce30f3766167f43de4a96 Stats: 580 lines in 15 files changed: 463 ins; 64 del; 53 mod 8352437: Support --add-exports with -XX:+AOTClassLinking Reviewed-by: matsaave ------------- PR: https://git.openjdk.org/jdk/pull/24124 From dholmes at openjdk.org Wed Apr 2 02:04:09 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 2 Apr 2025 02:04:09 GMT Subject: RFR: 8353458: Don't pass -Wno-format-nonliteral to CFLAGS In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 13:22:47 GMT, Magnus Ihse Bursie wrote: > there was already a pragma but due to incorrect restrictions it did not apply to clang. How does the `__GNUC__` check affect clang?? Isn't that just for gcc? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24357#issuecomment-2771087761 From alanb at openjdk.org Wed Apr 2 06:13:11 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 2 Apr 2025 06:13:11 GMT Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups() can lock up target VM [v7] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 20:00:22 GMT, Chris Plummer wrote: >> Calling ThreadGroupReference.groups() from an event handler can cause a deadlock. Details in first comment. Tested with :jdk_lang on all supported platforms and tier1, tier2, tier3, and tier5 svc testing. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > minor comment update Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24236#pullrequestreview-2734755558 From azeller at openjdk.org Wed Apr 2 06:45:28 2025 From: azeller at openjdk.org (Arno Zeller) Date: Wed, 2 Apr 2025 06:45:28 GMT Subject: RFR: 8352419: Test tools/jpackage/share/ErrorTest.java#id0 and #id1 fail [v2] In-Reply-To: <4VAUOiGy-CZ8bcltzuA6RG-gx0uwZ5dTxU6b8FrThI0=.854b5ce8-6d6b-470a-83af-56e57259ef97@github.com> References: <1QksvVOulgv5y1TaYzDy8SomeWoYrGp0WgOU4GhLpwk=.ae5739b3-4ca0-462b-b4d7-4e0d8480572f@github.com> <4VAUOiGy-CZ8bcltzuA6RG-gx0uwZ5dTxU6b8FrThI0=.854b5ce8-6d6b-470a-83af-56e57259ef97@github.com> Message-ID: <3EvuXq2x9373EzIiM9ufaZ34e95IfaCQjCEIhnAcVvs=.13762a61-7702-4dc0-abb9-3c4f15b5c854@github.com> On Tue, 1 Apr 2025 19:00:56 GMT, Alexey Semenyuk wrote: >> Make tools/jpackage/share/ErrorTest.java test safely handle the case when native bundling is unavailable on the test host. >> >> Additionally: >> - If native bundling is unavailable on the test host, PackageTest will throw `jtreg.SkippedException` and mark the test as skipped instead of silently doing nothing. This should mark a few jpackage tests "skipped" in tests runs on Alpine Linux that doesn't support either .deb or .rpm packaging. >> - Get rid of the dependency on `jtreg.SkippedException` from `/jdk/test` lib as this exception can be thrown from almost every jpackage test because of the changes in PackageTest. Instead embed `jtreg.SkippedException` classfile in TKit.java source and load it from there. This is a less intrusive alternative to adding >> >> * @library /test/lib >> * @build jtreg.SkippedException >> >> in every jtreg test declaration > > Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'master' into JDK-8352419 > - Fix failure in PackageTestTest when native packaging is not available > - bash ./bin/blessed-modifier-order.sh test/jdk/tools/jpackage/ > - 8352419: Test tools/jpackage/share/ErrorTest.java#id0 and #id1 fail > - Add PackageType.throwSkippedExceptionIfNativePackagingUnavailable(). Stable order of platform package types. Make PackageTest fail if native packagers are unavailable. > - Get rid of dependency on "/test/lib" tets lib Test on Windows without WIX was successful - thanks for improving this! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24294#issuecomment-2771483413 From jwaters at openjdk.org Wed Apr 2 07:25:19 2025 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 2 Apr 2025 07:25:19 GMT Subject: RFR: 8304674: File java.c compile error with -fsanitize=address -O0 [v3] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 12:07:09 GMT, SendaoYan wrote: >> Hi all, >> File src/java.base/share/native/libjli/java.c compile error: control reaches end of non-void function [-Werror=return-type] with gcc options -fsanitize=address -O0. The function int JavaMain(void* _args) in this file will execute return ret in LEAVE() macro, but gcc with -O0 is not smart enough to recognized that the function already has return statement before at the end of function. It's a gcc bug which has been recorded by [80959](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80959), and below code snippet can demonstrate the gcc bug. I think we should disable return-type gcc warning for java.c file before the gcc bug has been fixed. Risk is low. >> >> >>> cat java.c >> char a() { >> return 0; >> int b; >> if (a(&b)) >> return 0; >> } >> >>> gcc -O0 -Wall -Wextra -Werror -O0 -c java.c -fsanitize=address >> java.c: In function ?a?: >> java.c:6:1: error: control reaches end of non-void function [-Werror=return-type] >> 6 | } >> | ^ >> cc1: all warnings being treated as errors > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > add "#if defined(__GNUC__)" to fix windows build warning I was going to suggest adding an && condition checking for ! __clang__ in the #if, but after some thinking I think it is not worth the trouble to add that. This looks good to go ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/24318#pullrequestreview-2734896635 From jwaters at openjdk.org Wed Apr 2 08:03:32 2025 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 2 Apr 2025 08:03:32 GMT Subject: RFR: 8353458: Don't pass -Wno-format-nonliteral to CFLAGS In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 02:00:39 GMT, David Holmes wrote: > > there was already a pragma but due to incorrect restrictions it did not apply to clang. > > How does the `__GNUC__` check affect clang?? Isn't that just for gcc? clang has a tendency to like to pretend to be other compilers, it defines __GNUC__ in addition to __clang__ and even defines _MSC_VER if you're compiling for Windows. This is why it's common in code to see the #ifdef __clang__ be the very first ifdef when checking for a compiler; It has to be first, otherwise the check wouldn't work. If I had to guess, while clang defines __GNUC__ it doesn't define it to the version number like gcc does, which is why the > 5 check failed in clang's case here ------------- PR Comment: https://git.openjdk.org/jdk/pull/24357#issuecomment-2771672196 From syan at openjdk.org Wed Apr 2 08:29:23 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 2 Apr 2025 08:29:23 GMT Subject: Integrated: 8304674: File java.c compile error with -fsanitize=address -O0 In-Reply-To: References: Message-ID: On Sun, 30 Mar 2025 15:07:36 GMT, SendaoYan wrote: > Hi all, > File src/java.base/share/native/libjli/java.c compile error: control reaches end of non-void function [-Werror=return-type] with gcc options -fsanitize=address -O0. The function int JavaMain(void* _args) in this file will execute return ret in LEAVE() macro, but gcc with -O0 is not smart enough to recognized that the function already has return statement before at the end of function. It's a gcc bug which has been recorded by [80959](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80959), and below code snippet can demonstrate the gcc bug. I think we should disable return-type gcc warning for java.c file before the gcc bug has been fixed. Risk is low. > > >> cat java.c > char a() { > return 0; > int b; > if (a(&b)) > return 0; > } > >> gcc -O0 -Wall -Wextra -Werror -O0 -c java.c -fsanitize=address > java.c: In function ?a?: > java.c:6:1: error: control reaches end of non-void function [-Werror=return-type] > 6 | } > | ^ > cc1: all warnings being treated as errors This pull request has now been integrated. Changeset: 9076673d Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/9076673d7df3c20bdb6e7fdf253030bc19a3d9dc Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod 8304674: File java.c compile error with -fsanitize=address -O0 Reviewed-by: ihse, jwaters ------------- PR: https://git.openjdk.org/jdk/pull/24318 From syan at openjdk.org Wed Apr 2 08:29:23 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 2 Apr 2025 08:29:23 GMT Subject: RFR: 8304674: File java.c compile error with -fsanitize=address -O0 In-Reply-To: <5XLdWLua54uHwdnZst3xc89s1ipMJijjEEWvN8jHavc=.d70404aa-ab13-4e91-ab42-aa173516b07e@github.com> References: <5XLdWLua54uHwdnZst3xc89s1ipMJijjEEWvN8jHavc=.d70404aa-ab13-4e91-ab42-aa173516b07e@github.com> Message-ID: On Mon, 31 Mar 2025 12:57:38 GMT, Magnus Ihse Bursie wrote: >> Hi all, >> File src/java.base/share/native/libjli/java.c compile error: control reaches end of non-void function [-Werror=return-type] with gcc options -fsanitize=address -O0. The function int JavaMain(void* _args) in this file will execute return ret in LEAVE() macro, but gcc with -O0 is not smart enough to recognized that the function already has return statement before at the end of function. It's a gcc bug which has been recorded by [80959](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80959), and below code snippet can demonstrate the gcc bug. I think we should disable return-type gcc warning for java.c file before the gcc bug has been fixed. Risk is low. >> >> >>> cat java.c >> char a() { >> return 0; >> int b; >> if (a(&b)) >> return 0; >> } >> >>> gcc -O0 -Wall -Wextra -Werror -O0 -c java.c -fsanitize=address >> java.c: In function ?a?: >> java.c:6:1: error: control reaches end of non-void function [-Werror=return-type] >> 6 | } >> | ^ >> cc1: all warnings being treated as errors > > While I normally advocate using DISABLE_WARNING in makefiles instead of pragmas, in this particular case I wonder if not a pragma in the `LEAVE` macro would be better? Thanks for the reviews @magicus @TheShermanTanker ------------- PR Comment: https://git.openjdk.org/jdk/pull/24318#issuecomment-2771787344 From mcimadamore at openjdk.org Wed Apr 2 08:33:24 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 2 Apr 2025 08:33:24 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v25] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 13:27:34 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Add lazy toSting for StableMap::values > - Make toString for reversed and sublist lazy src/java.base/share/classes/java/lang/StableValue.java line 2: > 1: /* > 2: * Copyright (c) 2024, 2025, Oracle and/or its affiliates. All rights reserved. Should this be 2024 or both 2024, 2025 ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024336784 From alanb at openjdk.org Wed Apr 2 08:38:01 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 2 Apr 2025 08:38:01 GMT Subject: RFR: 8353267: jmod create finds the wrong set of packages when class file are in non-package location Message-ID: <1ECZmIwkZ3iCpm_33bJxUO-GmFQwc0hqbwr9OQ2ljWo=.1cc1f217-6231-4ebf-a0aa-d8153b31e189@github.com> `jmod create` maps the contents of the module to a set of packages. This mapping derives illegal package names when class resources are located in non-package locations, e.g. in the META-INF tree. `jlink` also has an issue in this area and doesn't correctly determine if a resource is in a named package when the resource is class file in a non-package location. ------------- Commit messages: - Remove trailing space - Improve comment - Initial commit Changes: https://git.openjdk.org/jdk/pull/24362/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24362&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353267 Stats: 214 lines in 4 files changed: 180 ins; 6 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/24362.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24362/head:pull/24362 PR: https://git.openjdk.org/jdk/pull/24362 From mcimadamore at openjdk.org Wed Apr 2 08:39:37 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 2 Apr 2025 08:39:37 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v25] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 13:27:34 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Add lazy toSting for StableMap::values > - Make toString for reversed and sublist lazy src/java.base/share/classes/java/lang/StableValue.java line 50: > 48: > 49: /** > 50: * A stable value is a deferred holder of shallowly immutable content. The JEP introduces this terminology: > A stable value is an object, of type [StableValue](https://cr.openjdk.org/~pminborg/stable-values2/api/java.base/java/lang/StableValue.html), that holds a single data value, its content I'm not saying we should copy this definition -- but I note that the word `deferred holder` (and also `deferred` in general) only appears once (here) in the whole doc. On the other hand, I find many occurrences of `lazy`/`lazily computed`, so maybe you want to stick with that here: A stable value is a holder of shallowly immutable, lazily computed content. Or A stable value is a holder of shallowly immutable content that can be lazily computed. src/java.base/share/classes/java/lang/StableValue.java line 52: > 50: * A stable value is a deferred holder of shallowly immutable content. > 51: *

> 52: * A {@code StableValue} can be created using the factory method s/can be/is (more direct) -- here and elsewhere ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024346623 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024347188 From mcimadamore at openjdk.org Wed Apr 2 08:45:32 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 2 Apr 2025 08:45:32 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6] In-Reply-To: References: Message-ID: On Mon, 17 Mar 2025 02:56:11 GMT, Chen Liang wrote: >> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits: >> >> - Merge branch 'master' into implement-jep502 >> - Clean up exception messages and fix comments >> - Rename field >> - Rename method and fix comment >> - Rework reenterant logic >> - Use acquire semantics for reading rather than volatile semantics >> - Add missing null check >> - Simplify handling of sentinel, wrap, and unwrap >> - Fix JavaDoc issues >> - Fix members in StableEnumFunction >> - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f > > src/java.base/share/classes/java/lang/StableValue.java line 56: > >> 54: * , {@linkplain #orElse(Object) orElse()}, or {@linkplain #orElseSet(Supplier) orElseSet()}. >> 55: *

>> 56: * A stable value that is set is treated as a constant by the JVM, enabling the > > Before promoting the "constant" features, I would prefer more details about the transition to set - that setting is really a racy thing and only one actor succeeds in setting, and specify the memory effect (like the final field freeze) as a hb for the set and all subsequent gets that successfully observed that set. I think the issue in this passage is that it's trying to do two things at once: on the one hand, it's saying "better performance" (which I agree with @liach that maybe it's not the primary concern at this point in time). But it's also saying "you can use it in more places than `final`" -- which is a rather big implication of the API. I suggest focusing on this latter aspect here -- and move any performance-related consideration to a section later (e.g. constant folding) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024354673 From mcimadamore at openjdk.org Wed Apr 2 08:45:34 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 2 Apr 2025 08:45:34 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v25] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 13:27:34 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Add lazy toSting for StableMap::values > - Make toString for reversed and sublist lazy src/java.base/share/classes/java/lang/StableValue.java line 95: > 93: *

> 94: * Note that the holder value can only be set at most once. > 95: * In the example above, the {@code logger} field is declared {@code final} which is This is not 100% true -- a final non-static field is not treated as a constant by the VM (at least not yet). Again, I suggest to keep this discussion focused on the fact that `logger` is a `final` stable value field. The holder is created eagerly, but the _content_ is initialized lazily (in the `getLogger` method). So, same similar to `final` (can only be set once) -- but more flexible. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024356190 From mcimadamore at openjdk.org Wed Apr 2 08:49:33 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 2 Apr 2025 08:49:33 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v25] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 13:27:34 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Add lazy toSting for StableMap::values > - Make toString for reversed and sublist lazy src/java.base/share/classes/java/lang/StableValue.java line 164: > 162: * for that parameter value. A stable int function is created via the > 163: * {@linkplain StableValue#intFunction(int, IntFunction) StableValue.intFunction()} > 164: * factory. Upon creation, the input range (i.e. [0, size)) is specified together with maybe better to surround the range `[0, size` in a code block, or something similar? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024375858 From mcimadamore at openjdk.org Wed Apr 2 08:58:37 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 2 Apr 2025 08:58:37 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v25] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 13:27:34 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Add lazy toSting for StableMap::values > - Make toString for reversed and sublist lazy src/java.base/share/classes/java/lang/StableValue.java line 169: > 167: * > 168: * {@snippet lang = java: > 169: * public final class SqrtUtil { Maybe this example can be improved? E.g. how about a general utility class which speeds up computation of common square roots, up to a certain number. Then you can have a method that takes a number and returns its square root (it will check if the number is less than the threshold and use the stable function cache in that case). E.g. this would be very nice with primitive type patterns: if (input instanceof int i && i < threshold) { return SQRT.apply(i); } else { return Math.sqrt(input); } (it's probably not great to refer to another preview here -- maybe we can keep this example for another time). But, if you use something like `pow`, that might be easier (as then you can only worry about int/long inputs) ? src/java.base/share/classes/java/lang/StableValue.java line 187: > 185: * uses it to compute a result (of type {@code R}) that is then cached by the backing > 186: * stable value storage for that parameter value. A stable function is created via the > 187: * {@linkplain StableValue#function(Set, Function) StableValue.function()} factory. In general I'm not a big fan of using a `linkplain` in this way -- e.g. `@link` will already put the signature of the function -- here you are providing an alternate label with a simpler signature -- but that is less precise, and if there's overload it doesn't work great. I suggest to just use `@link` in these cases (here and elsewhere) -- unless you have a better english text to describe what's in the link -- e.g. this is ok: A stable function is created via a {@linkplain StableValue#function(Set, Function) factory}. (but not sure it's worth the trouble). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024385407 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024390856 From alanb at openjdk.org Wed Apr 2 09:40:18 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 2 Apr 2025 09:40:18 GMT Subject: RFR: 8352971: Increase maximum number of hold counts for ReentrantReadWriteLock In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 11:30:11 GMT, Alan Bateman wrote: >> I'm breaking this change out as a separate improvement, since it will not be generally possible to adjust these limits on the j.u.c primitives since they might already use a backing `long` to pack in information which needs to be updated atomically (would require 128-bit atomics to widen them, and it still infeasible to change return types of pre-existing APIs). > > We'll need to double check serialization compatibility as the "sync" field is in the serial form. > @AlanBateman I was able to serialize a RRWL created before this patch and deserialize it after this patch. Okay, so we serialize a FairSync or NonfairSync when they are a AQS. When we deserialize, they will be a AQLS. It works because the internal classes haven't been renamed. If either internal class were to be renamed then we've get a CNFE. So I think what you have is okay and there's no compatibility or interop issue created at this time. However, having "sync" in the serial form is technical debt that will surface at some point. Ideally's RRWL's serial form would have something else to persistent the "fairness" bit as that is also it needs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24261#issuecomment-2771959548 From alanb at openjdk.org Wed Apr 2 09:40:36 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 2 Apr 2025 09:40:36 GMT Subject: RFR: 8352971: Increase maximum number of hold counts for ReentrantReadWriteLock In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 16:19:16 GMT, Viktor Klang wrote: > I'm breaking this change out as a separate improvement, since it will not be generally possible to adjust these limits on the j.u.c primitives since they might already use a backing `long` to pack in information which needs to be updated atomically (would require 128-bit atomics to widen them, and it still infeasible to change return types of pre-existing APIs). test/jdk/java/util/concurrent/tck/ReentrantReadWriteLock20Test.java line 75: > 73: try { > 74: latch.await(); > 75: } catch (InterruptedException ie) {} Something isn't right if any of these virtual threads are interrupted so I think failure needs to be set if there is any exception in the runnable. test/jdk/java/util/concurrent/tck/ReentrantReadWriteLock20Test.java line 94: > 92: next.join(); > 93: } catch (InterruptedException ie) { > 94: } I don't think we should swallow InterruptedException here. The only reason that the main thread will be interrupted here is if jtreg is trying to timeout the test, so I think it should throw when that happens. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24261#discussion_r2024466317 PR Review Comment: https://git.openjdk.org/jdk/pull/24261#discussion_r2024467711 From duke at openjdk.org Wed Apr 2 09:44:17 2025 From: duke at openjdk.org (Oleksii Sylichenko) Date: Wed, 2 Apr 2025 09:44:17 GMT Subject: RFR: 8353489: Increase Timeout and Improve Windows Compatibility in Basic.java Test Message-ID: This PR proposes three improvements to the `Basic.java` test: 1. Increase Timeout - The current timeout is insufficient when running the test in IntelliJ IDEA. - I propose increasing it by one minute. - The timeout value was last modified on May 13, 2010 (commit [56131863a71c](https://github.com/openjdk/jdk/commit/56131863a71ca552d0a881364bd2b3581e13f058)) and has remained unchanged since then. 2. Fix Incompatibility with Windows (Cygwin vs. Native) - One of the tests executes the `echo` command. - This works in Cygwin but fails when running the test in a pure Windows environment (e.g., IntelliJ IDEA). - I propose replacing echo with `cmd /c echo.`, which produces the same output (a single newline) in Windows, ensuring compatibility. 3. Prevent Autorun Scripts in the `cmd /c set` Command - The test runs `cmd /c set`, but in Windows, this may trigger autorun scripts. - I propose adding the `/d` options to prevent autorun scripts from affecting the test results. These changes improve test reliability and ensure compatibility across different environments. Testing: - Verified that the test runs successfully in IntelliJ IDEA without timeout issues. - Confirmed that `cmd /c echo.` produces the expected output in Windows. - Ensured that `cmd /d /c set` correctly lists environment variables without executing autorun scripts. # Detailed Description ## echo The following test fails in a clean Windows environment (e.g., when run from IntelliJ IDEA without Cygwin): //---------------------------------------------------------------- // Test Runtime.exec(...envp...) with envstrings without any `=' //---------------------------------------------------------------- with following error: Cannot run program "echo": CreateProcess error=2, The system cannot find the file specified ## cmd.exe /c set The following test fails in a Windows environment under specific conditions: //---------------------------------------------------------------- // Test Runtime.exec(...envp...) // Check for sort order of environment variables on Windows. //---------------------------------------------------------------- with following error: >'+=+ BAZ=GORP CONDA_BAT=C:\.......\\miniconda3\\condabin\\conda.bat CONDA_EXE=C:\........\\miniconda3\\Scripts\\conda.exe CONDA_SHLVL=0 FOO=BAR PATH=C:\.........\\miniconda3\\condabin; QUUX= SystemRoot=C:\\WINDOWS _=_ ~=~ '< not equal to '+=+ BAZ=GORP FOO=BAR QUUX= SystemRoot=C:\\WINDOWS _=_ ~=~ ' **Reason** In my environment, Miniconda was installed, which adds a script execution to the **autorun** of `cmd`. This script sets additional environment variables that break this test. To reproduce this bug, you can manually add a custom script to the autorun. I have described the steps in detail in my article: [AutoRun for Windows Command Processor (cmd.exe)](https://www.linkedin.com/pulse/autorun-windows-command-processor-cmdexe-oleksii-sylichenko-fofif). ## Changes - increase timeout by one minute - remove unused import **For Windows** - add `/d` to `winEnvCommand` - to disable the execution of AutoRun commands - replace `echo` with `cmd /c echo.` ------------- Commit messages: - Basic.java: Changes: https://git.openjdk.org/jdk/pull/23933/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23933&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353489 Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23933.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23933/head:pull/23933 PR: https://git.openjdk.org/jdk/pull/23933 From pminborg at openjdk.org Wed Apr 2 09:44:15 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 2 Apr 2025 09:44:15 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v25] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 08:29:54 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add lazy toSting for StableMap::values >> - Make toString for reversed and sublist lazy > > src/java.base/share/classes/java/lang/StableValue.java line 2: > >> 1: /* >> 2: * Copyright (c) 2024, 2025, Oracle and/or its affiliates. All rights reserved. > > Should this be 2024 or both 2024, 2025 ? The files that were created in 2024 and were changed in 2025 have both. > src/java.base/share/classes/java/lang/StableValue.java line 52: > >> 50: * A stable value is a deferred holder of shallowly immutable content. >> 51: *

>> 52: * A {@code StableValue} can be created using the factory method > > s/can be/is (more direct) -- here and elsewhere The reason we use the notion "can be" rather than "is" is that a `StableValue` can alternately be created via the `StableValue.of(initialValue)` method. In the latter case, it is already set. > src/java.base/share/classes/java/lang/StableValue.java line 95: > >> 93: *

>> 94: * Note that the holder value can only be set at most once. >> 95: * In the example above, the {@code logger} field is declared {@code final} which is > > This is not 100% true -- a final non-static field is not treated as a constant by the VM (at least not yet). Again, I suggest to keep this discussion focused on the fact that `logger` is a `final` stable value field. The holder is created eagerly, but the _content_ is initialized lazily (in the `getLogger` method). So, same similar to `final` (can only be set once) -- but more flexible. Now that we have removed the VM-specific handling of fields declared as `StableValue`, this is true. I will take a look at improving the wording. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024403082 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024424746 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024431748 From mcimadamore at openjdk.org Wed Apr 2 09:45:52 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 2 Apr 2025 09:45:52 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v25] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 13:27:34 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Add lazy toSting for StableMap::values > - Make toString for reversed and sublist lazy src/java.base/share/classes/java/lang/StableValue.java line 257: > 255: * which are held by stable values: > 256: * {@snippet lang = java: > 257: * public final class DependencyUtil { I think the fibonacci example is great -- and is probably enough for this section. We also had, at some point, a nice ASCII art of the computations involved in the fibonacci, which might be useful to illustrate your claim re. "dependency graph". Do you think you can recover that ? src/java.base/share/classes/java/lang/StableValue.java line 327: > 325: * (e.g. {@linkplain #trySet(Object) trySet()}) > 326: * {@linkplain java.util.concurrent##MemoryVisibility happens-before} > 327: * any subsequent read operation (e.g. {@linkplain #orElseThrow()}). Maybe we should clarify that a write of V happens before a read that can see that can see that V. E.g. a successful `trySet` doesn't happen before _any_ `orElseThrow` _in general_ -- (because `orElseThrow` can also throw -- in which case you know you arrived too early). Also, there's operations in there like `orElseSet` which both get and set -- so perhaps things should be specified a bit more -- e.g. maybe we should talk about a successful read operation as: * `orElseThrow` that doesn't throw * `orElse` which dosn't return the fallback value * `orElseGet` that doesn't run the provided supplier We can also talk about a succseful write operation: * a `trySet` which returns true * a `setOrThrow` that doesn't throw * an `orElseSet` that runs the supplier Then we can say that a _successful_ write operation happens before a _successful_ read operation. src/java.base/share/classes/java/lang/StableValue.java line 371: > 369: > 370: /** > 371: * {@return {@code true} if the content was set to the provided {@code value}, I find this description a bit confusing -- as written it almost looks like a predicate -- e.g. test if this stable value is set with the value I'm providing. But the important thing here is the side-effect -- so I feel the javadoc for this method should be much less about what this method returns, and much more about what the method actually does. (`setOrThrow` seems to be better in this respect) src/java.base/share/classes/java/lang/StableValue.java line 378: > 376: * @param value to set > 377: */ > 378: boolean trySet(T value); This can probably throw `IllegalStateException` too right -- e.g. if used inside a supplier passed to `orElseSet` ? src/java.base/share/classes/java/lang/StableValue.java line 416: > 414: * When this method returns successfully, the content is always set. > 415: *

> 416: * This method will always return the same witness value regardless if invoked by will always return/always returns (more direct) src/java.base/share/classes/java/lang/StableValue.java line 435: > 433: * > 434: * @param value to set > 435: * @throws IllegalStateException if the content was already set The javadoc speaks about "a stable value is set", and not "content is set". Make sure we're using terminology consistenty src/java.base/share/classes/java/lang/StableValue.java line 461: > 459: * An unset stable value has no content. > 460: *

> 461: * The returned stable value is not {@link Serializable}. I find the claim about serializable a bit odd here. Perhaps in some `implSpec`/`apiNote` at the toplevel? src/java.base/share/classes/java/lang/StableValue.java line 507: > 505: * @param the type of results supplied by the returned supplier > 506: */ > 507: static Supplier supplier(Supplier original) { I think that here and in all other functional/collection factories, we should document that `toString` will never cause a value to be computed. src/java.base/share/classes/java/lang/StableValue.java line 591: > 589: *

> 590: * The returned list is an {@linkplain Collection##unmodifiable unmodifiable} list > 591: * whose size is known at construction. The list's elements are computed via the s/"is known at construction"/`{@code size}` ? src/java.base/share/classes/java/lang/StableValue.java line 603: > 601: * caller and no value for the element is recorded. > 602: *

> 603: * The returned list and its {@link List#subList(int, int) subList} views implement Perhaps the most important fact to note here is that the returned lists via `subList` and friends are _also_ stable lists! src/java.base/share/classes/java/lang/StableValue.java line 657: > 655: * @param the type of mapped values in the returned map > 656: */ > 657: static Map map(Set keys, Like `List`, a map can also generate other kinds of collections: 1. an entry set (`Map::entrySet`) 2. a key set (`Map::keySet`) 3. a value set (`Map::values`) We should make it clear that calling (1) and (3) will result in materializing the values for the map -- we do not have "lazy" views for such sets. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024400960 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024413931 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024425037 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024438670 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024431337 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024442624 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024445136 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024469913 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024451560 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024454122 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024461588 From mcimadamore at openjdk.org Wed Apr 2 09:46:08 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 2 Apr 2025 09:46:08 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v25] In-Reply-To: References: Message-ID: <1g6Ccqa5D3jftEihHE72_0nzYTrtsTLrf1XqodVNAVE=.b7f4b80c-6227-4696-96e8-c5b214dcdfa7@github.com> On Wed, 2 Apr 2025 09:13:32 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add lazy toSting for StableMap::values >> - Make toString for reversed and sublist lazy > > src/java.base/share/classes/java/lang/StableValue.java line 371: > >> 369: >> 370: /** >> 371: * {@return {@code true} if the content was set to the provided {@code value}, > > I find this description a bit confusing -- as written it almost looks like a predicate -- e.g. test if this stable value is set with the value I'm providing. But the important thing here is the side-effect -- so I feel the javadoc for this method should be much less about what this method returns, and much more about what the method actually does. (`setOrThrow` seems to be better in this respect) I also note that, so far, we have always referred to the thing contained in a stable value as "content" (bonus points for that -- as that's also the terminology we settled on in the JEP!). But here (and in other methods) we fall back to `value` -- which is generic, and also a bit confusing with respect to `StableValue` itself. > src/java.base/share/classes/java/lang/StableValue.java line 416: > >> 414: * When this method returns successfully, the content is always set. >> 415: *

>> 416: * This method will always return the same witness value regardless if invoked by > > will always return/always returns (more direct) `witness value` -- what is that? Also, why do we say that here -- does it mean that `orElseThrow` can return different values? Overall I'm not sure what this last section wants to add that wasn't already covered at the beginning by the very clear: > The provided {@code supplier} is guaranteed to be invoked at most once if it completes without throwing an exception. > src/java.base/share/classes/java/lang/StableValue.java line 461: > >> 459: * An unset stable value has no content. >> 460: *

>> 461: * The returned stable value is not {@link Serializable}. > > I find the claim about serializable a bit odd here. Perhaps in some `implSpec`/`apiNote` at the toplevel? Same in other factories... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024427669 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024436050 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024448413 From ihse at openjdk.org Wed Apr 2 09:50:58 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 2 Apr 2025 09:50:58 GMT Subject: Integrated: 8353458: Don't pass -Wno-format-nonliteral to CFLAGS In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 13:22:47 GMT, Magnus Ihse Bursie wrote: > The proper way to disable warnings is to use the DISABLED_WARNINGS arguments. In this particular case, there was already a pragma but due to incorrect restrictions it did not apply to clang. This pull request has now been integrated. Changeset: 4a50778a Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/4a50778a2614a69dabf45fbdd57c0226f95a7f6a Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod 8353458: Don't pass -Wno-format-nonliteral to CFLAGS Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/24357 From ihse at openjdk.org Wed Apr 2 09:50:53 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 2 Apr 2025 09:50:53 GMT Subject: RFR: 8353458: Don't pass -Wno-format-nonliteral to CFLAGS In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 08:00:25 GMT, Julian Waters wrote: > How does the __GNUC__ check affect clang?? Isn't that just for gcc? No, clang disguises as gcc in several ways, and this is one of them. In effect, you can consider `__GNUC__` to be not a check for a particular compiler, but for compliance with the "standard" that gcc defined. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24357#issuecomment-2771978347 From alanb at openjdk.org Wed Apr 2 10:07:19 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 2 Apr 2025 10:07:19 GMT Subject: RFR: 8353322: Specification of ChoiceFormat#parse(String, ParsePosition) is inadequate [v3] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 20:32:45 GMT, Justin Lu wrote: >> Please review this PR which specifies the `ChoiceFormat#parse(String, ParsePosition)` method. A corresponding CSR is filed. The current specification is simply "Parses a Number from the input text" which does not indicate how the value is returned. The criteria for a match, as well as no match should be made clear. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Address further comments src/java.base/share/classes/java/text/ChoiceFormat.java line 562: > 560: /** > 561: * Parses a {@code Number} from the input text, the subtype of which is always > 562: * {@code Double}. The value returned is the {@code limit} corresponding I wonder if we could improve the first sentence, e.g. "Parses the input text from the parse position as a Double" ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24361#discussion_r2024515574 From mcimadamore at openjdk.org Wed Apr 2 10:09:09 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 2 Apr 2025 10:09:09 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v25] In-Reply-To: References: Message-ID: <2wQHHcMoVkF7rnUmt2QXy3b8TVeupYV7rqRd1ogSKYw=.28558659-e29f-4612-b7dc-2b3620d8364a@github.com> On Wed, 2 Apr 2025 09:13:21 GMT, Per Minborg wrote: >> src/java.base/share/classes/java/lang/StableValue.java line 52: >> >>> 50: * A stable value is a deferred holder of shallowly immutable content. >>> 51: *

>>> 52: * A {@code StableValue} can be created using the factory method >> >> s/can be/is (more direct) -- here and elsewhere > > The reason we use the notion "can be" rather than "is" is that a `StableValue` can alternately be created via the `StableValue.of(initialValue)` method. In the latter case, it is already set. You are correct. I suggest replacing `can be created` with `is typically created` (to suggest we envision that to be the common case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024517745 From pminborg at openjdk.org Wed Apr 2 10:48:13 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 2 Apr 2025 10:48:13 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v26] In-Reply-To: References: Message-ID: > Implement JEP 502. > > The PR passes tier1-tier3 tests. Per Minborg has updated the pull request incrementally with three additional commits since the last revision: - Use static final SV in the snippets - Update StableValue main description - Add stable collections to MOAT tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23972/files - new: https://git.openjdk.org/jdk/pull/23972/files/be84045a..0e4ebba9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=24-25 Stats: 35 lines in 7 files changed: 19 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/23972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 PR: https://git.openjdk.org/jdk/pull/23972 From alan.bateman at oracle.com Wed Apr 2 10:52:22 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Wed, 2 Apr 2025 11:52:22 +0100 Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream In-Reply-To: <8d453b79099b4675bce7f3902e3cd74f@amazon.com> References: <8721e7784793451187c5b6099eb37756@amazon.com> <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu> <8d453b79099b4675bce7f3902e3cd74f@amazon.com> Message-ID: <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com> On 31/03/2025 16:51, Engebretson, John wrote: > > ? Alan ? is this what you have in mind: > > ByteArrayOutputStream.getInstance() // returns existing class > > ByteArrayOutputStream.getUnsynchronizedInstance() // returns subclass > of BAOS that overrides the synchronization > > ByteArrayOutputStream.getInstance() // > returns the new class > > BAOS has been synchronized since JDK 1.0. While undocumented, it's possible that existing code depends on this 30 year behavior so I think we are stuck with it. The removal of biased locking has spurred on a few complaints that the class is needlessly synchronized. A static factory to return an unsynchronized BOAS would help but only if it isn't used with code that assumes all operations are synchronized. So I think we will have to look at the API docs for this. It's not clear that we need to have several implementation with different performance tradeoffs. So I think part of the exploration will be to see what usages perform better or worse, and whether having a parameter to specify the initial size or some hint of the max size would help the discussion. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From pminborg at openjdk.org Wed Apr 2 11:39:20 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 2 Apr 2025 11:39:20 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v27] In-Reply-To: References: Message-ID: > Implement JEP 502. > > The PR passes tier1-tier3 tests. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Improve examples ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23972/files - new: https://git.openjdk.org/jdk/pull/23972/files/0e4ebba9..ab842789 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=25-26 Stats: 61 lines in 1 file changed: 45 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/23972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 PR: https://git.openjdk.org/jdk/pull/23972 From pminborg at openjdk.org Wed Apr 2 11:39:20 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 2 Apr 2025 11:39:20 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v25] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 09:17:23 GMT, Per Minborg wrote: >> src/java.base/share/classes/java/lang/StableValue.java line 95: >> >>> 93: *

>>> 94: * Note that the holder value can only be set at most once. >>> 95: * In the example above, the {@code logger} field is declared {@code final} which is >> >> This is not 100% true -- a final non-static field is not treated as a constant by the VM (at least not yet). Again, I suggest to keep this discussion focused on the fact that `logger` is a `final` stable value field. The holder is created eagerly, but the _content_ is initialized lazily (in the `getLogger` method). So, same similar to `final` (can only be set once) -- but more flexible. > > Now that we have removed the VM-specific handling of fields declared as `StableValue`, this is true. I will take a look at improving the wording. I've used `static` fields now to get out of the muddy waters of trusted final fields, records etc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024641249 From mcimadamore at openjdk.org Wed Apr 2 11:40:07 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 2 Apr 2025 11:40:07 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v25] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 11:34:24 GMT, Per Minborg wrote: >> Now that we have removed the VM-specific handling of fields declared as `StableValue`, this is true. I will take a look at improving the wording. > > I've used `static` fields now to get out of the muddy waters of trusted final fields, records etc. I didn't mean to say "this is not true, so use a `static final` instead". What I meant was more "let's not dive into VM-specific details now" (see my other comment on the topic), and just focus on semantics instead. Then let's put all the constant-folding related stuff somewhere else. I liked using non-static final fields! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024646178 From mcimadamore at openjdk.org Wed Apr 2 11:46:01 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 2 Apr 2025 11:46:01 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v25] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 11:37:56 GMT, Maurizio Cimadamore wrote: >> I've used `static` fields now to get out of the muddy waters of trusted final fields, records etc. > > I didn't mean to say "this is not true, so use a `static final` instead". What I meant was more "let's not dive into VM-specific details now" (see my other comment on the topic), and just focus on semantics instead. Then let's put all the constant-folding related stuff somewhere else. I liked using non-static final fields! Basically: drop all references to "performance" and "constant folding" everywhere. And then introduce a section dedicated to that topic which talks a bit about how the content of a SV is trusted not to change by the JVM, which enables constant-folding optimizations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024654143 From mcimadamore at openjdk.org Wed Apr 2 11:46:02 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 2 Apr 2025 11:46:02 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v27] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 11:39:20 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Improve examples src/java.base/share/classes/java/lang/StableValue.java line 209: > 207: * private SqrtUtil(){} > 208: * > 209: * private static final Set CACHED_KEYS = Set.of(1, 2, 4, 8, 16, 32); This is not the same as before, is it? E.g. in the previous example, we had cached results for `0 <= input < CACHED_SIZE`. But here we hand-pick some values for which we know the square root is also an int. I think the two example should be the same, so as to attract attention on how stable int function vs. stable function works... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024651152 From mcimadamore at openjdk.org Wed Apr 2 11:46:03 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 2 Apr 2025 11:46:03 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v27] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 11:41:30 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve examples > > src/java.base/share/classes/java/lang/StableValue.java line 209: > >> 207: * private SqrtUtil(){} >> 208: * >> 209: * private static final Set CACHED_KEYS = Set.of(1, 2, 4, 8, 16, 32); > > This is not the same as before, is it? E.g. in the previous example, we had cached results for `0 <= input < CACHED_SIZE`. But here we hand-pick some values for which we know the square root is also an int. I think the two example should be the same, so as to attract attention on how stable int function vs. stable function works... The same discrepancy is present in the list vs. map examples ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024651952 From mcimadamore at openjdk.org Wed Apr 2 11:50:04 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 2 Apr 2025 11:50:04 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v25] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 11:43:40 GMT, Maurizio Cimadamore wrote: >> I didn't mean to say "this is not true, so use a `static final` instead". What I meant was more "let's not dive into VM-specific details now" (see my other comment on the topic), and just focus on semantics instead. Then let's put all the constant-folding related stuff somewhere else. I liked using non-static final fields! > > Basically: drop all references to "performance" and "constant folding" everywhere. And then introduce a section dedicated to that topic which talks a bit about how the content of a SV is trusted not to change by the JVM, which enables constant-folding optimizations. The reason I'm suggesting this is that what's constant-folded is kind of a moving target, so we don't want to say/promise too much. For now, we can say that if the SV, or the stable function/collection is stored in a static/final field then its content will be constant-folded. But we know that there's other stuff in the pipeline (e.g. [this JEP](https://openjdk.org/jeps/8349536)) which will affect this picture, and enable for more constant-folding when accessing SV and stable functions/collections. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024659484 From pminborg at openjdk.org Wed Apr 2 11:57:09 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 2 Apr 2025 11:57:09 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v25] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 09:00:38 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add lazy toSting for StableMap::values >> - Make toString for reversed and sublist lazy > > src/java.base/share/classes/java/lang/StableValue.java line 257: > >> 255: * which are held by stable values: >> 256: * {@snippet lang = java: >> 257: * public final class DependencyUtil { > > I think the fibonacci example is great -- and is probably enough for this section. We also had, at some point, a nice ASCII art of the computations involved in the fibonacci, which might be useful to illustrate your claim re. "dependency graph". Do you think you can recover that ? I found it! Soon to be added! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024670474 From pminborg at openjdk.org Wed Apr 2 12:05:08 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 2 Apr 2025 12:05:08 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v28] In-Reply-To: References: Message-ID: > Implement JEP 502. > > The PR passes tier1-tier3 tests. Per Minborg has updated the pull request incrementally with three additional commits since the last revision: - Add a dependency layout image snippet - Wip on condy - Use @enablePreview in MOAT ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23972/files - new: https://git.openjdk.org/jdk/pull/23972/files/ab842789..de3d5616 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=26-27 Stats: 30 lines in 3 files changed: 25 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 PR: https://git.openjdk.org/jdk/pull/23972 From pminborg at openjdk.org Wed Apr 2 12:05:08 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 2 Apr 2025 12:05:08 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v27] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 11:42:03 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/java/lang/StableValue.java line 209: >> >>> 207: * private SqrtUtil(){} >>> 208: * >>> 209: * private static final Set CACHED_KEYS = Set.of(1, 2, 4, 8, 16, 32); >> >> This is not the same as before, is it? E.g. in the previous example, we had cached results for `0 <= input < CACHED_SIZE`. But here we hand-pick some values for which we know the square root is also an int. I think the two example should be the same, so as to attract attention on how stable int function vs. stable function works... > > The same discrepancy is present in the list vs. map examples There are two fundamental variants. One with `CACHED_SIZE` (for list and int function) and one with `CACHED_KEYS` (for map and function). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024679612 From pminborg at openjdk.org Wed Apr 2 12:41:09 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 2 Apr 2025 12:41:09 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v29] In-Reply-To: References: Message-ID: > Implement JEP 502. > > The PR passes tier1-tier3 tests. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Specify what is a successful read/write operation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23972/files - new: https://git.openjdk.org/jdk/pull/23972/files/de3d5616..d69d7c35 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=27-28 Stats: 13 lines in 1 file changed: 12 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 PR: https://git.openjdk.org/jdk/pull/23972 From pminborg at openjdk.org Wed Apr 2 12:52:01 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 2 Apr 2025 12:52:01 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v30] In-Reply-To: References: Message-ID: <59rIh-KVn70dE6VSH1Di-738P6fd4cYvKtNTgKfpe30=.1fed9a9c-20b4-4d50-869b-7e9524b49ecc@github.com> > Implement JEP 502. > > The PR passes tier1-tier3 tests. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Rename variable and clarify get operations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23972/files - new: https://git.openjdk.org/jdk/pull/23972/files/d69d7c35..55f2c90e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=28-29 Stats: 17 lines in 2 files changed: 2 ins; 1 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/23972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 PR: https://git.openjdk.org/jdk/pull/23972 From pminborg at openjdk.org Wed Apr 2 12:55:11 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 2 Apr 2025 12:55:11 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v25] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 09:21:17 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add lazy toSting for StableMap::values >> - Make toString for reversed and sublist lazy > > src/java.base/share/classes/java/lang/StableValue.java line 378: > >> 376: * @param value to set >> 377: */ >> 378: boolean trySet(T value); > > This can probably throw `IllegalStateException` too right -- e.g. if used inside a supplier passed to `orElseSet` ? Nice catch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024766795 From pminborg at openjdk.org Wed Apr 2 12:59:07 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 2 Apr 2025 12:59:07 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v25] In-Reply-To: <1g6Ccqa5D3jftEihHE72_0nzYTrtsTLrf1XqodVNAVE=.b7f4b80c-6227-4696-96e8-c5b214dcdfa7@github.com> References: <1g6Ccqa5D3jftEihHE72_0nzYTrtsTLrf1XqodVNAVE=.b7f4b80c-6227-4696-96e8-c5b214dcdfa7@github.com> Message-ID: On Wed, 2 Apr 2025 09:26:52 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/java/lang/StableValue.java line 461: >> >>> 459: * An unset stable value has no content. >>> 460: *

>>> 461: * The returned stable value is not {@link Serializable}. >> >> I find the claim about serializable a bit odd here. Perhaps in some `implSpec`/`apiNote` at the toplevel? > > Same in other factories... We had that originally and then I got the comment to move them to the factories so I am happy to do either as soon as we agree on the best way to do it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024774672 From pminborg at openjdk.org Wed Apr 2 13:07:55 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 2 Apr 2025 13:07:55 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v31] In-Reply-To: References: Message-ID: > Implement JEP 502. > > The PR passes tier1-tier3 tests. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Address various comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23972/files - new: https://git.openjdk.org/jdk/pull/23972/files/55f2c90e..260086db Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=30 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=29-30 Stats: 11 lines in 1 file changed: 5 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 PR: https://git.openjdk.org/jdk/pull/23972 From vklang at openjdk.org Wed Apr 2 13:12:03 2025 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 2 Apr 2025 13:12:03 GMT Subject: RFR: 8352971: Increase maximum number of hold counts for ReentrantReadWriteLock In-Reply-To: References: Message-ID: <7nuBme2ZUc4sCr4M_fCv2WCwh8-RGfUEbCV25gS4DTQ=.c2b7a8cb-92a8-4672-9ce3-967591ea6fab@github.com> On Wed, 2 Apr 2025 09:36:51 GMT, Alan Bateman wrote: >> I'm breaking this change out as a separate improvement, since it will not be generally possible to adjust these limits on the j.u.c primitives since they might already use a backing `long` to pack in information which needs to be updated atomically (would require 128-bit atomics to widen them, and it still infeasible to change return types of pre-existing APIs). > > test/jdk/java/util/concurrent/tck/ReentrantReadWriteLock20Test.java line 75: > >> 73: try { >> 74: latch.await(); >> 75: } catch (InterruptedException ie) {} > > Something isn't right if any of these virtual threads are interrupted so I think failure needs to be set if there is any exception in the runnable. @AlanBateman Yeah, that seems sensible, I'll amend the PR. > test/jdk/java/util/concurrent/tck/ReentrantReadWriteLock20Test.java line 94: > >> 92: next.join(); >> 93: } catch (InterruptedException ie) { >> 94: } > > I don't think we should swallow InterruptedException here. The only reason that the main thread will be interrupted here is if jtreg is trying to timeout the test, so I think it should throw when that happens. @AlanBateman Yeah, that seems sensible, I'll amend the PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24261#discussion_r2024796937 PR Review Comment: https://git.openjdk.org/jdk/pull/24261#discussion_r2024796839 From pminborg at openjdk.org Wed Apr 2 13:16:25 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 2 Apr 2025 13:16:25 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v32] In-Reply-To: References: Message-ID: > Implement JEP 502. > > The PR passes tier1-tier3 tests. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Mention the impact of toString and equals ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23972/files - new: https://git.openjdk.org/jdk/pull/23972/files/260086db..b8d52436 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=31 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=30-31 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 PR: https://git.openjdk.org/jdk/pull/23972 From pminborg at openjdk.org Wed Apr 2 13:17:04 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 2 Apr 2025 13:17:04 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v25] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 09:34:57 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add lazy toSting for StableMap::values >> - Make toString for reversed and sublist lazy > > src/java.base/share/classes/java/lang/StableValue.java line 657: > >> 655: * @param the type of mapped values in the returned map >> 656: */ >> 657: static Map map(Set keys, > > Like `List`, a map can also generate other kinds of collections: > 1. an entry set (`Map::entrySet`) > 2. a key set (`Map::keySet`) > 3. a value set (`Map::values`) > > We should make it clear that calling (1) and (3) will result in materializing the values for the map -- we do not have "lazy" views for such sets. These constructs are also lazy actually which is cool. Operating on them will only materialize values on demand. We should document that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024806772 From pminborg at openjdk.org Wed Apr 2 13:22:44 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 2 Apr 2025 13:22:44 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: > Implement JEP 502. > > The PR passes tier1-tier3 tests. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Add info that Map#values and Map#entrySet are stable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23972/files - new: https://git.openjdk.org/jdk/pull/23972/files/b8d52436..5dbcd4d0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=32 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=31-32 Stats: 4 lines in 2 files changed: 3 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 PR: https://git.openjdk.org/jdk/pull/23972 From duke at openjdk.org Wed Apr 2 13:39:22 2025 From: duke at openjdk.org (David Beaumont) Date: Wed, 2 Apr 2025 13:39:22 GMT Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method [v12] In-Reply-To: References: Message-ID: <4d6IvkYgvkCB8AMWG-hWDDANRjyBh9E-eMhnVIvKVb4=.0e80d6be-0ab4-4444-859d-7fca46aa5d58@github.com> > 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method. > > 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package. > 2. Add explanatory comments to various affected methods. > 3. Add a test to ensure deadlocks no longer occur. > > Note that this change does not address issue in MemoryHandler (see JDK-8349208). David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Reworking user warnings about synchronization and deadlocking based on Joe's comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23491/files - new: https://git.openjdk.org/jdk/pull/23491/files/43c76119..15cad6ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=10-11 Stats: 28 lines in 3 files changed: 24 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23491.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23491/head:pull/23491 PR: https://git.openjdk.org/jdk/pull/23491 From alanb at openjdk.org Wed Apr 2 13:48:12 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 2 Apr 2025 13:48:12 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 13:22:44 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Add info that Map#values and Map#entrySet are stable src/java.base/share/classes/java/lang/StableValue.java line 455: > 453: * provided to the {@link #orElseSet(Supplier)} method. > 454: */ > 455: boolean trySet(T content); I assume the intent is that trySet can only return at most true once but the current wording suggests that two threads racing to set the same content would return true, or sequential calls to trySet to set the same content would return true. Does this need to be clarified? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024863484 From alanb at openjdk.org Wed Apr 2 13:58:09 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 2 Apr 2025 13:58:09 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v25] In-Reply-To: References: <1g6Ccqa5D3jftEihHE72_0nzYTrtsTLrf1XqodVNAVE=.b7f4b80c-6227-4696-96e8-c5b214dcdfa7@github.com> Message-ID: On Wed, 2 Apr 2025 12:56:23 GMT, Per Minborg wrote: >> Same in other factories... > > We had that originally and then I got the comment to move them to the factories so I am happy to do either as soon as we agree on the best way to do it. I'm also puzzled as to why this is here as it becomes part of the spec and a testable assertion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024883972 From alanb at openjdk.org Wed Apr 2 13:58:10 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 2 Apr 2025 13:58:10 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 13:22:44 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Add info that Map#values and Map#entrySet are stable src/java.base/share/classes/java/lang/StableValue.java line 494: > 492: *

> 493: * The provided {@code supplier} will only be invoked once even if invoked from > 494: * several threads unless the {@code supplier} throws an exception. Is this the supplier instance or any supplier? Just wondering about the case where two threads are invoke it with different instances (for whatever reason), I can't tell from the javadoc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024880627 From dfuchs at openjdk.org Wed Apr 2 14:00:10 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 2 Apr 2025 14:00:10 GMT Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method [v12] In-Reply-To: <4d6IvkYgvkCB8AMWG-hWDDANRjyBh9E-eMhnVIvKVb4=.0e80d6be-0ab4-4444-859d-7fca46aa5d58@github.com> References: <4d6IvkYgvkCB8AMWG-hWDDANRjyBh9E-eMhnVIvKVb4=.0e80d6be-0ab4-4444-859d-7fca46aa5d58@github.com> Message-ID: On Wed, 2 Apr 2025 13:39:22 GMT, David Beaumont wrote: >> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method. >> >> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package. >> 2. Add explanatory comments to various affected methods. >> 3. Add a test to ensure deadlocks no longer occur. >> >> Note that this change does not address issue in MemoryHandler (see JDK-8349208). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Reworking user warnings about synchronization and deadlocking based on Joe's comments. src/java.logging/share/classes/java/util/logging/Handler.java line 61: > 59: * their {@link #publish(LogRecord)} method, or calls to {@code > 60: * super.publish()}, since these are always expected to need to process and > 61: * format user-supplied arguments. I had to read this paragraph twice to realize it didn't say that subclasses shouldn't call super.publish(). What about slightly changing the wording as follows: Suggestion: * As such, general purpose {@code Handler} subclasses should not synchronize * their {@link #publish(LogRecord)} method, or call {@code * super.publish()} while holding locks, since these are typically expected to need to process and * format user-supplied arguments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r2024881280 From vklang at openjdk.org Wed Apr 2 14:13:18 2025 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 2 Apr 2025 14:13:18 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: <4nLcumfsB_JNPi8xU5DZnorZvhllSjUz-zfop_CXXx8=.7122f5cf-6f22-4cc1-ba3e-cb57ade07e53@github.com> On Wed, 2 Apr 2025 13:22:44 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Add info that Map#values and Map#entrySet are stable src/java.base/share/classes/java/lang/StableValue.java line 50: > 48: > 49: /** > 50: * A stable value is a holder of shallowly immutable content that can be lazily computed. This reads as if the content can only be shallowly immutable (not deeply immutable). How about saying "effectively immutable" instead? src/java.base/share/classes/java/lang/StableValue.java line 103: > 101: * instead, where the content is atomically and lazily computed via a > 102: * {@linkplain Supplier supplier}. In the example below, the supplier is provided in the > 103: * form of a lambda expression: I suspect that developers might use the aforementioned snippet without knowing that under a race multiple logger instances may be created (even if only one is then used). So I'd put a comment above trySet indicating that. src/java.base/share/classes/java/lang/StableValue.java line 130: > 128: *

> 129: * Furthermore, {@code orElseSet()} guarantees that the supplier provided is > 130: * evaluated only once, even when {@code logger.orElseSet()} is invoked concurrently. Suggestion: * evaluated at most once, even when {@code logger.orElseSet()} is invoked concurrently. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024907517 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024915663 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024917749 From alanb at openjdk.org Wed Apr 2 14:13:18 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 2 Apr 2025 14:13:18 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 13:22:44 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Add info that Map#values and Map#entrySet are stable src/java.base/share/classes/java/lang/StableValue.java line 649: > 647: * be thrown. > 648: * > 649: * @param inputs the set of (non-null) allowed input values You might get asked what the behavior is when the inputs set contains the null element. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024903511 From vklang at openjdk.org Wed Apr 2 14:13:18 2025 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 2 Apr 2025 14:13:18 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: <4nLcumfsB_JNPi8xU5DZnorZvhllSjUz-zfop_CXXx8=.7122f5cf-6f22-4cc1-ba3e-cb57ade07e53@github.com> References: <4nLcumfsB_JNPi8xU5DZnorZvhllSjUz-zfop_CXXx8=.7122f5cf-6f22-4cc1-ba3e-cb57ade07e53@github.com> Message-ID: On Wed, 2 Apr 2025 14:06:22 GMT, Viktor Klang wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Add info that Map#values and Map#entrySet are stable > > src/java.base/share/classes/java/lang/StableValue.java line 50: > >> 48: >> 49: /** >> 50: * A stable value is a holder of shallowly immutable content that can be lazily computed. > > This reads as if the content can only be shallowly immutable (not deeply immutable). > > How about saying "effectively immutable" instead? Or "observably immutable"? ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024910652 From vklang at openjdk.org Wed Apr 2 14:19:17 2025 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 2 Apr 2025 14:19:17 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: <7fCQwgQorg40yMBV-P0rBkgCuPFzOQVc5ZJnRE2fQYI=.2ee4d560-b9e1-4a29-b254-5bdcafb5c884@github.com> On Wed, 2 Apr 2025 13:22:44 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Add info that Map#values and Map#entrySet are stable src/java.base/share/classes/java/lang/StableValue.java line 162: > 160: * A stable int function is a function that takes an {@code int} parameter and > 161: * uses it to compute a result that is then cached by the backing stable value storage > 162: * for that parameter value. A stable int function is created via the Suggestion: * for that parameter value. A stable IntFunction is created via the src/java.base/share/classes/java/lang/StableValue.java line 172: > 170: * public final class SqrtUtil { > 171: * > 172: * private SqrtUtil(){} Suggestion: * private SqrtUtil() {} src/java.base/share/classes/java/lang/StableValue.java line 242: > 240: * private static final int CACHED_SIZE = 10; > 241: * > 242: * private SqrtUtil(){} Suggestion: * private SqrtUtil() {} ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024922015 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024923703 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024926886 From forax at univ-mlv.fr Wed Apr 2 14:33:57 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 2 Apr 2025 16:33:57 +0200 (CEST) Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) In-Reply-To: References: Message-ID: <1257824626.204034517.1743604437041.JavaMail.zimbra@univ-eiffel.fr> Hi Per, last week, at JChateau, we had a one hour session about stable values, I've build the JDK with this PR so we can discuss about it. To present the API, i start from the double check locking, rewriting it to use the StableValue API. The main remark was that methods like orElseSet() or isSet() are hard to used correctly. In my opinion, the current API is a mix of a high level API and a low-level API but it's too easy to misuse the low-level API. high level: - methods supplier(), list() and map() Those are easy to use low level: - methods: of, of(value), orElseSet, setOrThrow(), etc Those are hard to use properly. I think, not necessary in this PR, that the current API should be separated into two different classes, one in java.lang with the high level API (the static methods other than Of() and one in java.util.concurrent with the low level API where you have to know what you are doing (like with any classes of java.util.concurrent). regards, R?mi ----- Original Message ----- > From: "Per Minborg" > To: "compiler-dev" , "core-libs-dev" , "hotspot-dev" > , "security-dev" > Sent: Thursday, March 13, 2025 12:20:10 PM > Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) > Implement JEP 502. > > The PR passes tier1-tier3 tests. > > ------------- > > Commit messages: > - Use acquire semantics for reading rather than volatile semantics > - Add missing null check > - Simplify handling of sentinel, wrap, and unwrap > - Fix JavaDoc issues > - Fix members in StableEnumFunction > - Address some comments in the PR > - Merge branch 'master' into implement-jep502 > - Revert change > - Fix copyright issues > - Update JEP number > - ... and 231 more: https://git.openjdk.org/jdk/compare/4cf63160...09ca44e6 > > Changes: https://git.openjdk.org/jdk/pull/23972/files > Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=00 > Issue: https://bugs.openjdk.org/browse/JDK-8351565 > Stats: 3980 lines in 30 files changed: 3949 ins; 18 del; 13 mod > Patch: https://git.openjdk.org/jdk/pull/23972.diff > Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 > > PR: https://git.openjdk.org/jdk/pull/23972 From mcimadamore at openjdk.org Wed Apr 2 15:01:24 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 2 Apr 2025 15:01:24 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v27] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 12:00:31 GMT, Per Minborg wrote: >> The same discrepancy is present in the list vs. map examples > > There are two fundamental variants. One with `CACHED_SIZE` (for list and int function) and one with `CACHED_KEYS` (for map and function). Yes - but they cache different things -- the first caches results for values 0-9 -- the second cached results for 1, 2, 4, 8, 16, 32. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025022198 From ihse at openjdk.org Wed Apr 2 15:03:47 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 2 Apr 2025 15:03:47 GMT Subject: RFR: 8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH In-Reply-To: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> Message-ID: On Tue, 1 Apr 2025 09:13:45 GMT, Joachim Kern wrote: > In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so. > > The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed. This seems reasonable to me. But there is so much old yucky stuff going on with the JDK bootstrapping issues, that I still get a bit nervous every time someone changes it. Do you know *why* we do this, i.e. modify LD_LIBRARY_PATH? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24351#issuecomment-2772870911 From ihse at openjdk.org Wed Apr 2 15:16:31 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 2 Apr 2025 15:16:31 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables 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. ------------- Commit messages: - Revert "8352766: Problemlist hotspot tier1 tests requiring tools that are not included in static JDK" - Add build and main launcher support for relaunchers - Add native relaunchers - Simplify and prepare the main.c launcher Changes: https://git.openjdk.org/jdk/pull/24380/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346719 Stats: 659 lines in 9 files changed: 518 ins; 111 del; 30 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 Wed Apr 2 15:16:31 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 2 Apr 2025 15:16:31 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 14:54:35 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. A bit of discussion/rationale for this PR: * I did some preparation of the main launcher in 1d6c2ea66918667c2e9ef7619565cb3676a352d2. The old launcher code had a lot of weird stuff in `define.h` (which was not just defines, as the name implies). I simplified this and inlined it directly into main.c. I also renamed variables prefixed `const_`, because most of them will not be that after this PR, and it did not seem to bring much value to point this out in the name. * Any changes in main.c apart from these are within `#ifdef STATIC_BUILD` only, and should not affect the normal launcher. * The main launcher need some additional information to be able to launch any tool except the main "java" itself. Normally this is "hard-coded" into different builds of main.c by the use of compiler defines passed by the build. The approach I used for the static launcher is to pass this information as special system properties, with a name starting with `javaLauncher`. This will be treated as normal system properties by the launcher, but the additional code activated in the static build of the launcher will also interpret these values, and set the variables corresponding to how they would have been hardcoded in the dynamic launcher. * This could have been achieved by using shell script/bat file relaunchers instead. However, that seemed more risky, since it would change the launchers from native binaries to text files. On Windows, for instance, other programs might look for "javac.exe" and not consider "javac.bat" to be acceptable. * Finally, a commonly asked question when I developed this has been: "Could you not just symlink the java binary with different names, and then dispatch it depending on how it was called?". This is a common and clever technique, but it is not suitable here. First, it will not work on Windows. Secondly, it would require us to stuff all knowledge of all launchers into the main java binary. This solution, in contrast, distributes this knowledge out to every individual tool, making it possible to add new tools without modifying the main static binary. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-2772911175 From vromero at openjdk.org Wed Apr 2 15:31:50 2025 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 2 Apr 2025 15:31:50 GMT Subject: RFR: 8344708: Compiler Implementation of Module Import Declarations [v3] In-Reply-To: References: Message-ID: On Mon, 31 Mar 2025 17:40:25 GMT, Jan Lahoda wrote: >> This is a patch to finalize the module imports feature. Please see: >> https://bugs.openjdk.org/browse/JDK-8344700 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Fixing test. src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Startup.java line 340: > 338: */ > 339: static Startup defaultStartup(int sourceLevel, boolean preview, MessageHandler mh) { > 340: boolean startup24 = sourceLevel < 25; should we use a constant here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23801#discussion_r2025076240 From joehw at openjdk.org Wed Apr 2 16:54:47 2025 From: joehw at openjdk.org (Joe Wang) Date: Wed, 2 Apr 2025 16:54:47 GMT Subject: RFR: 8353234: Refactor XMLSecurityPropertyManager In-Reply-To: References: Message-ID: <58if9Ho9vc3Vy1EULyUVwyNCBv1iQYok4uq1hlRYRA0=.22c100cb-dd68-470a-9eaf-057b48328cfe@github.com> On Mon, 31 Mar 2025 17:42:20 GMT, Joe Wang wrote: > Refactor XMLSecurityPropertyManager. > The Xerces and Xalan components each had its own XMLSecurityManager and XMLSecurityPropertyManager. In a previous fix, the former had been unified as part of that changeset. This change will allow future changes to handle XMLSecurityManager and XMLSecurityPropertyManager in a similar manner. > > No material change has been made to the classes. The new classes were based on the classes in xalan/utils with a methods merged from that in xerces/utils. Update on the JCK failure: it appeared it was caused by a previous change to the JDK built-in Catalog, not this patch. I've created a JCK report (https://bugs.openjdk.org/browse/JCK-7322355). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24334#issuecomment-2773175195 From jlahoda at openjdk.org Wed Apr 2 16:59:16 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 2 Apr 2025 16:59:16 GMT Subject: RFR: 8344708: Compiler Implementation of Module Import Declarations [v4] In-Reply-To: References: Message-ID: > This is a patch to finalize the module imports feature. Please see: > https://bugs.openjdk.org/browse/JDK-8344700 Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Reflecting review feedback - avoiding hardcoded constants. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23801/files - new: https://git.openjdk.org/jdk/pull/23801/files/067a0444..d66703c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23801&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23801&range=02-03 Stats: 19 lines in 3 files changed: 4 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/23801.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23801/head:pull/23801 PR: https://git.openjdk.org/jdk/pull/23801 From jlahoda at openjdk.org Wed Apr 2 16:59:17 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 2 Apr 2025 16:59:17 GMT Subject: RFR: 8344708: Compiler Implementation of Module Import Declarations [v3] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 15:23:54 GMT, Vicente Romero wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixing test. > > src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Startup.java line 340: > >> 338: */ >> 339: static Startup defaultStartup(int sourceLevel, boolean preview, MessageHandler mh) { >> 340: boolean startup24 = sourceLevel < 25; > > should we use a constant here? Yes, there should be a constant. Done here: https://github.com/openjdk/jdk/pull/23801/commits/d66703c1cb4f9f532f9a98181b598fa45e55ef73 Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23801#discussion_r2025240134 From cjplummer at openjdk.org Wed Apr 2 17:07:02 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 2 Apr 2025 17:07:02 GMT Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups() can lock up target VM [v7] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 20:00:22 GMT, Chris Plummer wrote: >> Calling ThreadGroupReference.groups() from an event handler can cause a deadlock. Details in first comment. Tested with :jdk_lang on all supported platforms and tier1, tier2, tier3, and tier5 svc testing. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > minor comment update Thanks reviews Sergei, Jai, and Alan ------------- PR Comment: https://git.openjdk.org/jdk/pull/24236#issuecomment-2773202187 From cjplummer at openjdk.org Wed Apr 2 17:07:03 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 2 Apr 2025 17:07:03 GMT Subject: Integrated: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups() can lock up target VM In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 20:36:28 GMT, Chris Plummer wrote: > Calling ThreadGroupReference.groups() from an event handler can cause a deadlock. Details in first comment. Tested with :jdk_lang on all supported platforms and tier1, tier2, tier3, and tier5 svc testing. This pull request has now been integrated. Changeset: cc870d49 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/cc870d4960b3e121afc76df546228cda4b600632 Stats: 130 lines in 2 files changed: 128 ins; 0 del; 2 mod 8352088: Call of com.sun.jdi.ThreadReference.threadGroups() can lock up target VM Reviewed-by: alanb, jpai, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/24236 From kbarrett at openjdk.org Wed Apr 2 17:30:05 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 2 Apr 2025 17:30:05 GMT Subject: RFR: 8352565: Add native method implementation of Reference.get() [v3] In-Reply-To: References: Message-ID: > Please review this change which adds a native method providing the > implementation of Reference::get. Referece::get is an intrinsic candidate, so > this native method implementation is only used when the intrinsic is not. > > Currently there is intrinsic support by the interpreter, C1, C2, and graal, > which are always used. With this change we can later remove all the > per-platform interpreter intrinsic implementations, and might also remove the > C1 intrinsic implementation. > > Testing: > (1) mach5 tier1-6 normal (so using all the existing intrinsics). > (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled. Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: add package decl to test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24315/files - new: https://git.openjdk.org/jdk/pull/24315/files/37dc9b74..36bb26a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24315&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24315&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24315/head:pull/24315 PR: https://git.openjdk.org/jdk/pull/24315 From vromero at openjdk.org Wed Apr 2 17:43:51 2025 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 2 Apr 2025 17:43:51 GMT Subject: RFR: 8344708: Compiler Implementation of Module Import Declarations [v4] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 16:59:16 GMT, Jan Lahoda wrote: >> This is a patch to finalize the module imports feature. Please see: >> https://bugs.openjdk.org/browse/JDK-8344700 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review feedback - avoiding hardcoded constants. lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23801#pullrequestreview-2737083010 From jengebr at amazon.com Wed Apr 2 17:57:34 2025 From: jengebr at amazon.com (Engebretson, John) Date: Wed, 2 Apr 2025 17:57:34 +0000 Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream In-Reply-To: <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com> References: <8721e7784793451187c5b6099eb37756@amazon.com> <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu> <8d453b79099b4675bce7f3902e3cd74f@amazon.com> <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com> Message-ID: Thank you! I?ve updated the PR accordingly and summarized the benchmarks in the description. Here?s the short version: From: Alan Bateman Sent: Wednesday, April 2, 2025 5:52 AM To: Engebretson, John ; Markus KARG ; core-libs-dev at openjdk.org Subject: RE: [EXTERNAL] JDK-8352891 Performance improvements to ByteArrayOutputStream CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On 31/03/2025 16:51, Engebretson, John wrote: Alan ? is this what you have in mind: ByteArrayOutputStream.getInstance() // returns existing class ByteArrayOutputStream.getUnsynchronizedInstance() // returns subclass of BAOS that overrides the synchronization ByteArrayOutputStream.getInstance() // returns the new class BAOS has been synchronized since JDK 1.0. While undocumented, it's possible that existing code depends on this 30 year behavior so I think we are stuck with it. The removal of biased locking has spurred on a few complaints that the class is needlessly synchronized. A static factory to return an unsynchronized BOAS would help but only if it isn't used with code that assumes all operations are synchronized. So I think we will have to look at the API docs for this. It's not clear that we need to have several implementation with different performance tradeoffs. So I think part of the exploration will be to see what usages perform better or worse, and whether having a parameter to specify the initial size or some hint of the max size would help the discussion. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jengebr at amazon.com Wed Apr 2 18:04:01 2025 From: jengebr at amazon.com (Engebretson, John) Date: Wed, 2 Apr 2025 18:04:01 +0000 Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream In-Reply-To: References: <8721e7784793451187c5b6099eb37756@amazon.com> <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu> <8d453b79099b4675bce7f3902e3cd74f@amazon.com> <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com> Message-ID: Apologies, human error ? here?s the message I intended: Thank you! I?ve updated the PR accordingly and summarized the benchmarks in the description. Here?s the short version: * For small payloads, unsynchronized and optimized versions are 2-4x faster than base * For large payloads, optimized version is 3x faster than base or unsynchronized I discovered a capacity-related incompatibility between ByteArrayOutputStream and MemoryOutputStream: the size() method returns int, but MemoryOutputStream can exceed that value. I added range checking to size() and a new sizeAsLong() method? but it really makes me wonder MemoryOutputStream belongs as a subclass of ByteArrayOutputStream. It now has two significant incompatibilities: ignoring the protected fields, and size restrictions. John From: Engebretson, John Sent: Wednesday, April 2, 2025 12:58 PM To: 'Alan Bateman' ; Markus KARG ; core-libs-dev at openjdk.org Subject: RE: [EXTERNAL] JDK-8352891 Performance improvements to ByteArrayOutputStream Thank you! I?ve updated the PR accordingly and summarized the benchmarks in the description. Here?s the short version: From: Alan Bateman > Sent: Wednesday, April 2, 2025 5:52 AM To: Engebretson, John >; Markus KARG >; core-libs-dev at openjdk.org Subject: RE: [EXTERNAL] JDK-8352891 Performance improvements to ByteArrayOutputStream CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On 31/03/2025 16:51, Engebretson, John wrote: Alan ? is this what you have in mind: ByteArrayOutputStream.getInstance() // returns existing class ByteArrayOutputStream.getUnsynchronizedInstance() // returns subclass of BAOS that overrides the synchronization ByteArrayOutputStream.getInstance() // returns the new class BAOS has been synchronized since JDK 1.0. While undocumented, it's possible that existing code depends on this 30 year behavior so I think we are stuck with it. The removal of biased locking has spurred on a few complaints that the class is needlessly synchronized. A static factory to return an unsynchronized BOAS would help but only if it isn't used with code that assumes all operations are synchronized. So I think we will have to look at the API docs for this. It's not clear that we need to have several implementation with different performance tradeoffs. So I think part of the exploration will be to see what usages perform better or worse, and whether having a parameter to specify the initial size or some hint of the max size would help the discussion. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From lancea at openjdk.org Wed Apr 2 18:08:03 2025 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 2 Apr 2025 18:08:03 GMT Subject: RFR: 8353234: Refactor XMLSecurityPropertyManager In-Reply-To: References: Message-ID: On Mon, 31 Mar 2025 17:42:20 GMT, Joe Wang wrote: > Refactor XMLSecurityPropertyManager. > The Xerces and Xalan components each had its own XMLSecurityManager and XMLSecurityPropertyManager. In a previous fix, the former had been unified as part of that changeset. This change will allow future changes to handle XMLSecurityManager and XMLSecurityPropertyManager in a similar manner. > > No material change has been made to the classes. The new classes were based on the classes in xalan/utils with a methods merged from that in xerces/utils. Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24334#pullrequestreview-2737150500 From kbarrett at openjdk.org Wed Apr 2 18:33:16 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 2 Apr 2025 18:33:16 GMT Subject: RFR: 8352565: Add native method implementation of Reference.get() [v4] In-Reply-To: References: Message-ID: > Please review this change which adds a native method providing the > implementation of Reference::get. Referece::get is an intrinsic candidate, so > this native method implementation is only used when the intrinsic is not. > > Currently there is intrinsic support by the interpreter, C1, C2, and graal, > which are always used. With this change we can later remove all the > per-platform interpreter intrinsic implementations, and might also remove the > C1 intrinsic implementation. > > Testing: > (1) mach5 tier1-6 normal (so using all the existing intrinsics). > (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled. Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: - remove timeout by using waitForReferenceProcessing - make ill-timed gc in non-concurrent case less likely - fix test package use ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24315/files - new: https://git.openjdk.org/jdk/pull/24315/files/36bb26a1..234465f4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24315&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24315&range=02-03 Stats: 20 lines in 1 file changed: 14 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24315/head:pull/24315 PR: https://git.openjdk.org/jdk/pull/24315 From kbarrett at openjdk.org Wed Apr 2 18:37:53 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 2 Apr 2025 18:37:53 GMT Subject: RFR: 8352565: Add native method implementation of Reference.get() [v2] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 22:01:55 GMT, Brent Christian wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> parameterized return type of native get0 > > test/hotspot/jtreg/gc/TestNativeReferenceGet.java line 162: > >> 160: System.out.println("Testing nonconcurrent GC"); >> 161: clearReferents(); >> 162: strengthenReferents(); > > Might the GC clear refs between `clearReferents()` and `strengthenReferents()`? Yeah, an ill-timed GC between those operations would result in test failure. I've added a GC immediately before those operations to make that pretty unlikely. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2025385681 From kbarrett at openjdk.org Wed Apr 2 18:40:57 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 2 Apr 2025 18:40:57 GMT Subject: RFR: 8352565: Add native method implementation of Reference.get() [v4] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 18:33:16 GMT, Kim Barrett wrote: >> Please review this change which adds a native method providing the >> implementation of Reference::get. Referece::get is an intrinsic candidate, so >> this native method implementation is only used when the intrinsic is not. >> >> Currently there is intrinsic support by the interpreter, C1, C2, and graal, >> which are always used. With this change we can later remove all the >> per-platform interpreter intrinsic implementations, and might also remove the >> C1 intrinsic implementation. >> >> Testing: >> (1) mach5 tier1-6 normal (so using all the existing intrinsics). >> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled. > > Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: > > - remove timeout by using waitForReferenceProcessing > - make ill-timed gc in non-concurrent case less likely > - fix test package use test/hotspot/jtreg/gc/TestNativeReferenceGet.java line 137: > 135: } > 136: checkQueue(); // One last check after refproc complete. > 137: } catch (InterruptedException e) { Rather than using Reference.remove with a timeout, I've changed this to use waitForReferenceProcessing. That removes false passes (from reference processing being slow to deliver) and also removes the delay until timeout for the passing case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2025390205 From sgehwolf at openjdk.org Wed Apr 2 18:43:57 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 2 Apr 2025 18:43:57 GMT Subject: RFR: 8353185: Introduce the concept of upgradeable files in context of JEP493 Message-ID: For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool. When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows: 1. The list of upgradeable files is hard-coded to `lib/tzdb.dat` and `lib/security/cacerts`. Only those two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image. 2. The upgrade needs to be opt-in. Similar to `--ignore-signing-information` for signed modular JARs. A user needs to add `--upgrade-files=/` for it to succeed. `--upgrade-files` is a hidden `jlink` option since it only does anything for JEP 493 enabled builds. Users get a hint to apply the option if they so desire: Example: $ ./bin/jlink --add-modules java.base --output java.base-jdk Error: [..]/lib/security/cacerts has been modified Hint: lib/security/cacerts is an upgradeable file. Add --upgrade-files=java.base/lib/security/cacerts to allow the upgrade. using the hint we get: $ ./bin/jlink --add-modules java.base --output java.base-jdk --upgrade-files=java.base/lib/security/cacerts $ ./java.base-jdk/bin/java --list-modules java.base at 25-internal $ sha512sum ./java.base-jdk/lib/security/cacerts cf2b4c17161e79001c8e07def3de36c0d523f00a2a6b6e33893a2a3669d930957c11ac765dd29d5ff80e63ad100ef0258291891377f7133b997111ba97b15146 ./java.base-jdk/lib/security/cacerts $ sha512sum ./lib/security/cacerts cf2b4c17161e79001c8e07def3de36c0d523f00a2a6b6e33893a2a3669d930957c11ac765dd29d5ff80e63ad100ef0258291891377f7133b997111ba97b15146 ./lib/security/cacerts **Testing** - [ ] GHA - [x] `jdk/tools/jlink` jtreg tests - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files. Thoughts? ------------- Commit messages: - 8353185: Introduce the concept of upgradeable files in context of JEP 493 Changes: https://git.openjdk.org/jdk/pull/24388/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24388&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353185 Stats: 88 lines in 7 files changed: 70 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/24388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24388/head:pull/24388 PR: https://git.openjdk.org/jdk/pull/24388 From vklang at openjdk.org Wed Apr 2 18:59:17 2025 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 2 Apr 2025 18:59:17 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 13:22:44 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Add info that Map#values and Map#entrySet are stable Thanks for all the great work here, @minborg! I've accumulated some comments, suggestions, and questions?I hope they are helpful. Let me know if you want me to elaborate or explain anything. (I haven't reviewed the benchmarks (yet)) src/java.base/share/classes/java/lang/StableValue.java line 271: > 269: * public final class SqrtUtil { > 270: * > 271: * private SqrtUtil(){} Suggestion: * private SqrtUtil() {} src/java.base/share/classes/java/lang/StableValue.java line 277: > 275: * private static final Map SQRT = > 276: * // @link substring="map" target="#map(Set,Function)" : > 277: * StableValue.map(Set.of(1, 2, 4, 8, 16, 32), StrictMath::sqrt); Why not used CACHED_KEYS here? src/java.base/share/classes/java/lang/StableValue.java line 296: > 294: * > 295: *

Composing stable values

> 296: * A stable value can depend on other stable values, thereby creating a dependency graph Suggestion: * A stable value can depend on other stable values, forming a dependency graph src/java.base/share/classes/java/lang/StableValue.java line 304: > 302: * public final class DependencyUtil { > 303: * > 304: * private DependencyUtil(){} Suggestion: * private DependencyUtil() {} src/java.base/share/classes/java/lang/StableValue.java line 353: > 351: * } > 352: *} > 353: * Both {@code FIB} and {@code Fibonacci::fib} recurses into each other. Because the Suggestion: * Both {@code FIB} and {@code Fibonacci::fib} recurse into each other. Because the src/java.base/share/classes/java/lang/StableValue.java line 374: > 372: * If there are circular dependencies in a dependency graph, a stable value will > 373: * eventually throw a {@linkplain StackOverflowError} upon referencing elements in > 374: * a circularity. Is this still correct, I thought it detected reentrancy? src/java.base/share/classes/java/lang/StableValue.java line 377: > 375: * > 376: *

Thread Safety

> 377: * The content of a stable value is guaranteed to be set at most once. If competing Suggestion: * The contents of a stable value is guaranteed to be set at most once. If competing src/java.base/share/classes/java/lang/StableValue.java line 384: > 382: * (e.g. {@linkplain #trySet(Object) trySet()}) > 383: * {@linkplain java.util.concurrent##MemoryVisibility happens-before} > 384: * any subsequent read operation (e.g. {@linkplain #orElseThrow()}) that is successful. Suggestion: * any successful read operation (e.g. {@linkplain #orElseThrow()}). src/java.base/share/classes/java/lang/StableValue.java line 426: > 424: * {@linkplain java.lang.ref##reachability strongly reachable}. Clients are > 425: * advised that {@linkplain java.lang.ref##reachability reachable} stable values > 426: * will hold their set content perpetually. This reads like the contents of StableValues will never be garbage collected, even if the StableValue is no longer reachable. Is that intended? src/java.base/share/classes/java/lang/StableValue.java line 567: > 565: *

> 566: * The provided {@code original} supplier is guaranteed to be successfully invoked > 567: * at most once even in a multi-threaded environment. Competing threads invoking the There's a bit of a mix of "at most once" and "at-most-once". I'm fine with either but I prefer uniformity in spelling :) src/java.base/share/classes/java/lang/StableValue.java line 589: > 587: > 588: /** > 589: * {@return a new stable int function} "int function" reads strange to me. If we look at something like IntStream, it refers to "function": https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/IntStream.html#mapToObj(java.util.function.IntFunction) src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 62: > 60: @Override > 61: public R apply(E value) { > 62: if (!member.test(value.ordinal())) { Suggestion: if (!member.test(value.ordinal())) { // Implicit null-check of value src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 89: > 87: @Override > 88: public String toString() { > 89: final Collection>> entries = new ArrayList<>(); Might be good to size the entries to at most `size()`? src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 115: > 113: > 114: final int size = max - min + 1; > 115: final Class enumType = (Class)inputs.iterator().next().getClass(); I presume there's some external check to ensure that inputs is non-empty? src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 93: > 91: if (!trySet(content)) { > 92: throw new IllegalStateException("Cannot set the content to " + content + > 93: " because the content is already set: " + orElseThrow()); This might be problematic since it could surface confidential information inside exception messages (or even just produce very large strings). src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 125: > 123: Objects.requireNonNull(supplier); > 124: final Object t = wrappedContentAcquire(); > 125: return (t == null) ? orElseSetSlowPath(supplier) : unwrap(t); Is it faster to have the slow path on the true-case? src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 168: > 166: private void preventReentry() { > 167: if (Thread.holdsLock(this)) { > 168: throw new IllegalStateException("Recursing supplier detected"); Perhaps "Recursive initialization is not supported" src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 176: > 174: assert Thread.holdsLock(this); > 175: // This upholds the invariant, a `@Stable` field is written to at most once > 176: // We know we hold the monitor here so plain semantic is enough Perhaps better to move this to a javadoc/comment for the method itself: "must only be invoked while holding the monitor" src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 191: > 189: @ForceInline > 190: private static Object wrap(Object t) { > 191: return (t == null) ? NULL_SENTINEL : t; Personal preference, but it would seem more consistent to do the same check in wrap as in unwrap: Suggestion: return (t != null) ? t : NULL_SENTINEL; test/jdk/java/lang/StableValue/StableFunctionTest.java line 86: > 84: basic(inputs, MAPPER); > 85: basic(inputs, _ -> null); > 86: } Test for null mapper? test/jdk/java/lang/StableValue/StableFunctionTest.java line 101: > 99: assertTrue(cached.toString().endsWith("}")); > 100: // One between the values > 101: assertEquals(1L, cached.toString().chars().filter(ch -> ch == ',').count(), cached.toString()); Perhaps factor out the testing of the individual methods to different test cases to aid in debugging? Perhaps only call `cached.toString()` once? test/jdk/java/lang/StableValue/StableFunctionTest.java line 107: > 105: assertTrue(x1.getMessage().contains("ILLEGAL")); > 106: var x2 = assertThrows(IllegalArgumentException.class, () -> cached.apply(Value.ILLEGAL_AFTER)); > 107: assertTrue(x2.getMessage().contains("ILLEGAL")); Only tests a part of the message? test/jdk/java/lang/StableValue/StableFunctionTest.java line 115: > 113: Function f0 = StableValue.function(inputs, Value::asInt); > 114: Function f1 = StableValue.function(inputs, Value::asInt); > 115: assertTrue(f0.toString().contains("{}")); Not possible to test full string? test/jdk/java/lang/StableValue/StableFunctionTest.java line 136: > 134: assertTrue(cached.toString().contains(Value.THIRTEEN + "=.unset")); > 135: assertTrue(cached.toString().contains(Value.FORTY_TWO + "=.unset"), cached.toString()); > 136: assertTrue(cached.toString().endsWith("}")); Not possible to test full toString() representation? test/jdk/java/lang/StableValue/StableFunctionTest.java line 146: > 144: ref.set(cached); > 145: cached.apply(Value.FORTY_TWO); > 146: String toString = cached.toString(); I'd recommend caching the toString() representation in the other test cases as well ? test/jdk/java/lang/StableValue/StableFunctionTest.java line 147: > 145: cached.apply(Value.FORTY_TWO); > 146: String toString = cached.toString(); > 147: assertTrue(toString.contains("(this StableFunction)"), toString); Not possible to test full toString() representation? test/jdk/java/lang/StableValue/StableListTest.java line 114: > 112: Integer[] arr = new Integer[SIZE]; > 113: arr[INDEX] = 1; > 114: assertSame(arr, StableValue.list(INDEX, IDENTITY).toArray(arr)); No test for contents? test/jdk/java/lang/StableValue/StableListTest.java line 283: > 281: var lazy = StableValue.list(SIZE, i -> ref.get().apply(i)); > 282: ref.set(lazy::get); > 283: assertThrows(IllegalStateException.class, () -> lazy.get(INDEX)); Perhaps test the exception message to verify that it is indeed a recursion detection? test/jdk/java/lang/StableValue/StableMapTest.java line 143: > 141: assertTrue(actual.contains(key + "=.unset")); > 142: } > 143: assertTrue(actual.endsWith("}")); I guess the problem here is that the order of a map is not deterministic? test/jdk/java/lang/StableValue/StableMapTest.java line 178: > 176: } > 177: assertTrue(entrySet.toString().startsWith("[")); > 178: assertTrue(entrySet.toString().endsWith("]")); Cache toString() repr? test/jdk/java/lang/StableValue/StableMapTest.java line 201: > 199: } else { > 200: assertTrue(map.toString().contains(key + "=.unset")); > 201: } Cache map.toString() test/jdk/java/lang/StableValue/StableValueFactoriesTest.java line 36: > 34: import static org.junit.jupiter.api.Assertions.*; > 35: > 36: final class StableValueFactoriesTest { Just confirming?this is all that needs testing here? test/jdk/java/lang/StableValue/StableValueTest.java line 262: > 260: threads.forEach(StableValueTest::join); > 261: // There can only be one winner > 262: assertEquals(1, winner.cardinality()); AFAIK BitSet is not thread safe, so you have multiple threads writing to it?which may or may not provide the right guarantees to lean on for this test. Might be better to lean on CHM. test/jdk/java/lang/StableValue/StableValuesSafePublicationTest.java line 64: > 62: // fully initialized thanks to the HB properties of StableValue. > 63: int a; > 64: int b; Might be worth putting in some more fields to increase the chance of detecting a mismatch. test/jdk/java/lang/StableValue/StableValuesSafePublicationTest.java line 153: > 151: try { > 152: for (Thread t:threads) { > 153: long deadline = System.currentTimeMillis()+TimeUnit.MINUTES.toMillis(1); Why currentTimeMillis() here and nanoTime() above? test/jdk/java/lang/StableValue/TrustedFieldTypeTest.java line 120: > 118: // assertThrows(IllegalAccessException.class, () -> { > 119: field.set(stableValue, 13); > 120: // }); Leftover comments? ------------- PR Review: https://git.openjdk.org/jdk/pull/23972#pullrequestreview-2736446008 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024928142 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024929547 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024930451 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024930970 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024932995 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024942765 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024943338 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024946107 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024954825 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024978737 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025012681 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025045029 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025073406 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025077934 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025200236 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025201637 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025364611 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025365819 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025368554 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025377572 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025380044 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025380728 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025381378 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025383765 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025384849 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025384097 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025388876 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025392156 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025395553 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025396239 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025396838 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025400727 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025404972 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025407199 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025409083 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025411022 From vklang at openjdk.org Wed Apr 2 18:59:18 2025 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 2 Apr 2025 18:59:18 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 13:44:47 GMT, Alan Bateman wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Add info that Map#values and Map#entrySet are stable > > src/java.base/share/classes/java/lang/StableValue.java line 455: > >> 453: * provided to the {@link #orElseSet(Supplier)} method. >> 454: */ >> 455: boolean trySet(T content); > > I assume the intent is that trySet can only return at most true once but the current wording suggests that two threads racing to set the same content would return true, or sequential calls to trySet to set the same content would return true. Does this need to be clarified? I second this > src/java.base/share/classes/java/lang/StableValue.java line 494: > >> 492: *

>> 493: * The provided {@code supplier} will only be invoked once even if invoked from >> 494: * several threads unless the {@code supplier} throws an exception. > > Is this the supplier instance or any supplier? Just wondering about the case where two threads are invoke it with different instances (for whatever reason), I can't tell from the javadoc. Seconded ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024957920 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2024961992 From joehw at openjdk.org Wed Apr 2 19:06:56 2025 From: joehw at openjdk.org (Joe Wang) Date: Wed, 2 Apr 2025 19:06:56 GMT Subject: RFR: 8353234: Refactor XMLSecurityPropertyManager In-Reply-To: References: Message-ID: On Mon, 31 Mar 2025 17:42:20 GMT, Joe Wang wrote: > Refactor XMLSecurityPropertyManager. > The Xerces and Xalan components each had its own XMLSecurityManager and XMLSecurityPropertyManager. In a previous fix, the former had been unified as part of that changeset. This change will allow future changes to handle XMLSecurityManager and XMLSecurityPropertyManager in a similar manner. > > No material change has been made to the classes. The new classes were based on the classes in xalan/utils with a methods merged from that in xerces/utils. Thanks all for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24334#issuecomment-2773449918 From joehw at openjdk.org Wed Apr 2 19:06:57 2025 From: joehw at openjdk.org (Joe Wang) Date: Wed, 2 Apr 2025 19:06:57 GMT Subject: Integrated: 8353234: Refactor XMLSecurityPropertyManager In-Reply-To: References: Message-ID: On Mon, 31 Mar 2025 17:42:20 GMT, Joe Wang wrote: > Refactor XMLSecurityPropertyManager. > The Xerces and Xalan components each had its own XMLSecurityManager and XMLSecurityPropertyManager. In a previous fix, the former had been unified as part of that changeset. This change will allow future changes to handle XMLSecurityManager and XMLSecurityPropertyManager in a similar manner. > > No material change has been made to the classes. The new classes were based on the classes in xalan/utils with a methods merged from that in xerces/utils. This pull request has now been integrated. Changeset: 209e72d3 Author: Joe Wang URL: https://git.openjdk.org/jdk/commit/209e72d311234c8279289172dab2cbb255e4fed9 Stats: 618 lines in 26 files changed: 179 ins; 378 del; 61 mod 8353234: Refactor XMLSecurityPropertyManager Reviewed-by: naoto, iris, lancea ------------- PR: https://git.openjdk.org/jdk/pull/24334 From qamai at openjdk.org Wed Apr 2 19:25:14 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 2 Apr 2025 19:25:14 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 13:22:44 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Add info that Map#values and Map#entrySet are stable src/java.base/share/classes/java/lang/StableValue.java line 402: > 400: * race. Since stable functions and stable collections are built on top of > 401: * {@linkplain StableValue#orElseSet(Supplier) orElseSet()} they too are > 402: * thread safe and guarantee at-most-once-per-input invocation. Do we guarantee that there is a total order with respect to the suppliers that fail to return. You can take a look at the specification of [`std::call_once`](https://en.cppreference.com/w/cpp/thread/call_once) > All active calls on the same flag form a single total order consisting of zero or more exceptional calls, followed by one returning call. The end of each active call synchronizes-with the next active call in that order. > The return from the returning call synchronizes-with the returns from all passive calls on the same flag: this means that all concurrent calls to std::call_once are guaranteed to observe any side-effects made by the active call, with no additional synchronization. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025454935 From jlu at openjdk.org Wed Apr 2 19:46:13 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 2 Apr 2025 19:46:13 GMT Subject: RFR: 8353322: Specification of ChoiceFormat#parse(String, ParsePosition) is inadequate [v3] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 10:05:04 GMT, Alan Bateman wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> Address further comments > > src/java.base/share/classes/java/text/ChoiceFormat.java line 562: > >> 560: /** >> 561: * Parses a {@code Number} from the input text, the subtype of which is always >> 562: * {@code Double}. The value returned is the {@code limit} corresponding > > I wonder if we could improve the first sentence, e.g. "Parses the input text from the parse position as a Double" ? Right, I think we can make the sub-type wording simplification and should mention `ParsePosition`'s role in the method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24361#discussion_r2025480425 From jlu at openjdk.org Wed Apr 2 19:46:12 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 2 Apr 2025 19:46:12 GMT Subject: RFR: 8353322: Specification of ChoiceFormat#parse(String, ParsePosition) is inadequate [v4] In-Reply-To: References: Message-ID: > Please review this PR which specifies the `ChoiceFormat#parse(String, ParsePosition)` method. A corresponding CSR is filed. The current specification is simply "Parses a Number from the input text" which does not indicate how the value is returned. The criteria for a match, as well as no match should be made clear. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Alan's review - Improve first sentence ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24361/files - new: https://git.openjdk.org/jdk/pull/24361/files/d3864418..0ffdef97 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24361&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24361&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24361.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24361/head:pull/24361 PR: https://git.openjdk.org/jdk/pull/24361 From naoto at openjdk.org Wed Apr 2 19:50:53 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 2 Apr 2025 19:50:53 GMT Subject: RFR: 8353322: Specification of ChoiceFormat#parse(String, ParsePosition) is inadequate [v4] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 19:46:12 GMT, Justin Lu wrote: >> Please review this PR which specifies the `ChoiceFormat#parse(String, ParsePosition)` method. A corresponding CSR is filed. The current specification is simply "Parses a Number from the input text" which does not indicate how the value is returned. The criteria for a match, as well as no match should be made clear. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Alan's review - Improve first sentence Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24361#pullrequestreview-2737401960 From duke at openjdk.org Wed Apr 2 20:35:06 2025 From: duke at openjdk.org (duke) Date: Wed, 2 Apr 2025 20:35:06 GMT Subject: Withdrawn: 8346946: Allow class loaders to bind to layers for service loading In-Reply-To: <0BSZVYQ1bTJbPjGfcmK8OWw4hWl10_0ooq3EZuubNvg=.c68a7dc6-1801-48c4-b610-2cff1ddd4635@github.com> References: <0BSZVYQ1bTJbPjGfcmK8OWw4hWl10_0ooq3EZuubNvg=.c68a7dc6-1801-48c4-b610-2cff1ddd4635@github.com> Message-ID: On Thu, 2 Jan 2025 17:13:17 GMT, David M. Lloyd wrote: > When loading services by class loader (`ServiceLoader.load(Class,ClassLoader)`), the module layers bound to the given class loader are searched for services, along with the layers bound to class loader's parent, and so on. For non-hierarchical class loader arrangements, this breaks down because the parent class loader of non-hierarchical class loaders is typically `null` (i.e. the boot class loader), while the class loader might have multiple dependency class loaders which replace the role of parent. > > Add an API to `ClassLoader` which allows additional layers to be bound to the class loader for the purpose of service loading by class loader, without affecting reliable configuration of modules (see [JDK-8346439](https://bugs.openjdk.org/browse/JDK-8346439)), which allows non-hierarchical class loaders to resolve service providers in dependency class loaders. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22905 From mcimadamore at openjdk.org Wed Apr 2 21:40:14 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 2 Apr 2025 21:40:14 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: <4nLcumfsB_JNPi8xU5DZnorZvhllSjUz-zfop_CXXx8=.7122f5cf-6f22-4cc1-ba3e-cb57ade07e53@github.com> Message-ID: On Wed, 2 Apr 2025 14:07:45 GMT, Viktor Klang wrote: >> src/java.base/share/classes/java/lang/StableValue.java line 50: >> >>> 48: >>> 49: /** >>> 50: * A stable value is a holder of shallowly immutable content that can be lazily computed. >> >> This reads as if the content can only be shallowly immutable (not deeply immutable). >> >> How about saying "effectively immutable" instead? > > Or "observably immutable"? ? or... "immutable" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025638907 From duke at openjdk.org Wed Apr 2 21:59:32 2025 From: duke at openjdk.org (David Beaumont) Date: Wed, 2 Apr 2025 21:59:32 GMT Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method [v13] In-Reply-To: References: Message-ID: > 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method. > > 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package. > 2. Add explanatory comments to various affected methods. > 3. Add a test to ensure deadlocks no longer occur. > > Note that this change does not address issue in MemoryHandler (see JDK-8349208). David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Tweak wording. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23491/files - new: https://git.openjdk.org/jdk/pull/23491/files/15cad6ed..8db4c907 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=11-12 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23491.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23491/head:pull/23491 PR: https://git.openjdk.org/jdk/pull/23491 From duke at openjdk.org Wed Apr 2 21:59:32 2025 From: duke at openjdk.org (David Beaumont) Date: Wed, 2 Apr 2025 21:59:32 GMT Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method [v12] In-Reply-To: References: <4d6IvkYgvkCB8AMWG-hWDDANRjyBh9E-eMhnVIvKVb4=.0e80d6be-0ab4-4444-859d-7fca46aa5d58@github.com> Message-ID: On Wed, 2 Apr 2025 13:54:03 GMT, Daniel Fuchs wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Reworking user warnings about synchronization and deadlocking based on Joe's comments. > > src/java.logging/share/classes/java/util/logging/Handler.java line 61: > >> 59: * their {@link #publish(LogRecord)} method, or calls to {@code >> 60: * super.publish()}, since these are always expected to need to process and >> 61: * format user-supplied arguments. > > I had to read this paragraph twice to realize it didn't say that subclasses shouldn't call > super.publish(). What about slightly changing the wording as follows: > > Suggestion: > > * As such, general purpose {@code Handler} subclasses should not synchronize > * their {@link #publish(LogRecord)} method, or call {@code > * super.publish()} while holding locks, since these are typically expected to need to process and > * format user-supplied arguments. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r2025657511 From jlu at openjdk.org Wed Apr 2 22:32:23 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 2 Apr 2025 22:32:23 GMT Subject: RFR: 8353585: Provide ChoiceFormat#parse(String, ParsePosition) tests Message-ID: Please review this PR which provides unit tests for `ChoiceFormat#parse(String, ParsePosition)` to check default, multi match, and no match behavior. There were no existing relevant tests. ------------- Commit messages: - more cases + cleanup - init Changes: https://git.openjdk.org/jdk/pull/24395/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24395&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353585 Stats: 74 lines in 1 file changed: 74 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24395.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24395/head:pull/24395 PR: https://git.openjdk.org/jdk/pull/24395 From sathishkumar.thiyagarajan at gmail.com Thu Apr 3 00:36:31 2025 From: sathishkumar.thiyagarajan at gmail.com (Sathish Kumar Thiyagarajan) Date: Thu, 3 Apr 2025 06:06:31 +0530 Subject: Reg: Proposal: Generalized Number.parseNumber(String) Method for Java In-Reply-To: References: Message-ID: Thanks, Volkan. I agree that JSON parsers may have their own number codecs and may not necessarily rely on Integer.parseInt() or Long.parseLong(). I appreciate the clarification. Let me simplify my concern: I've tried converting a *String to a Number* and loading it into memory, and my expectation is that it should *occupy the least memory possible*. Wouldn't that be the ideal approach? If so, does it make sense to have a utility that helps achieve this efficiently? On Tue, 1 Apr 2025 at 14:12, Volkan Yaz?c? wrote: > Sathish, please see my response below. > > On Tue, Apr 1, 2025 at 7:58?AM Sathish Kumar Thiyagarajan < > sathishkumar.thiyagarajan at gmail.com> wrote: > >> However, *Jackson (and most JSON parsers) default to Integer for whole >> numbers* because they rely on Integer.parseInt(String), which is a safe >> fallback for most cases. >> > AFAIK, almost all JSON parsers use their own number codecs; i.e., encoders > and decoders. In the context of Jackson, `new ObjectMapper().readValue("1", > Number.class)` ends up in > `com.fasterxml.jackson.core.io.NumberInput::parseInt`, not > `Integer::parseInt`. There are multiple reasons for such libraries to roll > out their own number codecs; performance, matching the internal string > representation of library's choice, etc. It is very unlikely adding a > `Number::parseNumber` will bring any benefit to such use cases. > > [Quoting from another post > ] It > is better to frame feedback in the form of *"I?ve tried this, and run > into the following problem ..."* At the very least it helps us see what > problems people actually run into as opposed to what problems people > speculate that they or others may run into. > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Thu Apr 3 01:22:10 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 3 Apr 2025 01:22:10 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 14:31:46 GMT, Viktor Klang wrote: >> src/java.base/share/classes/java/lang/StableValue.java line 455: >> >>> 453: * provided to the {@link #orElseSet(Supplier)} method. >>> 454: */ >>> 455: boolean trySet(T content); >> >> I assume the intent is that trySet can only return at most true once but the current wording suggests that two threads racing to set the same content would return true, or sequential calls to trySet to set the same content would return true. Does this need to be clarified? > > I second this So maybe "was set to the provided content" -> "was set by this call" >> src/java.base/share/classes/java/lang/StableValue.java line 494: >> >>> 492: *

>>> 493: * The provided {@code supplier} will only be invoked once even if invoked from >>> 494: * several threads unless the {@code supplier} throws an exception. >> >> Is this the supplier instance or any supplier? Just wondering about the case where two threads are invoke it with different instances (for whatever reason), I can't tell from the javadoc. > > Seconded I personally think this is more of an implementation artifact for `StableValue::supplier` and doesn't merit its own API (as no other StableValue API utilizes the object monitor of a StableValue), but maybe we can adjust this in a later preview... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025846922 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2025850569 From henryjen at openjdk.org Thu Apr 3 02:49:52 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 3 Apr 2025 02:49:52 GMT Subject: RFR: 8353267: jmod create finds the wrong set of packages when class file are in non-package location In-Reply-To: <1ECZmIwkZ3iCpm_33bJxUO-GmFQwc0hqbwr9OQ2ljWo=.1cc1f217-6231-4ebf-a0aa-d8153b31e189@github.com> References: <1ECZmIwkZ3iCpm_33bJxUO-GmFQwc0hqbwr9OQ2ljWo=.1cc1f217-6231-4ebf-a0aa-d8153b31e189@github.com> Message-ID: <_s41rJI_tIsdpO6wnm6AZtldfxTc0CapD3f1BlflzY8=.fa9c37af-b7bc-4034-ad31-4f5a9d6cfd15@github.com> On Tue, 1 Apr 2025 17:33:43 GMT, Alan Bateman wrote: > `jmod create` maps the contents of the module to a set of packages. This mapping derives illegal package names when class resources are located in non-package locations, e.g. in the META-INF tree. `jlink` also has an issue in this area and doesn't correctly determine if a resource is in a named package when the resource is class file in a non-package location. Looks reasonable to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24362#issuecomment-2774242953 From duke at openjdk.org Thu Apr 3 02:56:54 2025 From: duke at openjdk.org (duke) Date: Thu, 3 Apr 2025 02:56:54 GMT Subject: Withdrawn: 8336017: Deprecate java.util.logging.LoggingMXBean, its implementation, and accessor method for removal In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 15:23:37 GMT, Kevin Walls wrote: > java.util.logging.LoggingMXBean and java.util.logging.LogManager::getLoggingMXBean are deprecated since JDK-8139982 in JDK 9. > > These deprecations should be uprated to state they are for future removal. > > java.util.logging.Logging (implements LoggingMXBean) should also be deprecated for removal. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/23271 From duke at openjdk.org Thu Apr 3 06:14:51 2025 From: duke at openjdk.org (Bernd) Date: Thu, 3 Apr 2025 06:14:51 GMT Subject: RFR: 8353185: Introduce the concept of upgradeable files in context of JEP 493 In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 18:39:57 GMT, Severin Gehwolf wrote: > For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool. > > When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows: > > 1. The list of upgradeable files is hard-coded to `lib/tzdb.dat` and `lib/security/cacerts`. Only those two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image. > 2. The upgrade needs to be opt-in. Similar to `--ignore-signing-information` for signed modular JARs. A user needs to add `--upgrade-files=/` for it to succeed. > > `--upgrade-files` is a hidden `jlink` option since it only does anything for JEP 493 enabled builds. Users get a hint to apply the option if they so desire: > > Example: > > > $ ./bin/jlink --add-modules java.base --output java.base-jdk > Error: [..]/lib/security/cacerts has been modified > Hint: lib/security/cacerts is an upgradeable file. Add --upgrade-files=java.base/lib/security/cacerts to allow the upgrade. > > > using the hint we get: > > > $ ./bin/jlink --add-modules java.base --output java.base-jdk --upgrade-files=java.base/lib/security/cacerts > $ ./java.base-jdk/bin/java --list-modules > java.base at 25-internal > $ sha512sum ./java.base-jdk/lib/security/cacerts > cf2b4c17161e79001c8e07def3de36c0d523f00a2a6b6e33893a2a3669d930957c11ac765dd29d5ff80e63ad100ef0258291891377f7133b997111ba97b15146 ./java.base-jdk/lib/security/cacerts > $ sha512sum ./lib/security/cacerts > cf2b4c17161e79001c8e07def3de36c0d523f00a2a6b6e33893a2a3669d930957c11ac765dd29d5ff80e63ad100ef0258291891377f7133b997111ba97b15146 ./lib/security/cacerts > > > **Testing** > > - [ ] GHA > - [x] `jdk/tools/jlink` jtreg tests > - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files. > > Thoughts? What about changes to conf files, especially Java.security (for hardening TLS settings) - or at least pointing to a include? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2774594563 From alanb at openjdk.org Thu Apr 3 06:25:50 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 3 Apr 2025 06:25:50 GMT Subject: RFR: 8353322: Specification of ChoiceFormat#parse(String, ParsePosition) is inadequate [v3] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 19:43:29 GMT, Justin Lu wrote: >> src/java.base/share/classes/java/text/ChoiceFormat.java line 562: >> >>> 560: /** >>> 561: * Parses a {@code Number} from the input text, the subtype of which is always >>> 562: * {@code Double}. The value returned is the {@code limit} corresponding >> >> I wonder if we could improve the first sentence, e.g. "Parses the input text from the parse position as a Double" ? > > Right, I think we can make the sub-type wording simplification and should mention `ParsePosition`'s role in the method. Thanks for the update, it reads much better now, no other comments from me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24361#discussion_r2026287478 From alanb at openjdk.org Thu Apr 3 06:33:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 3 Apr 2025 06:33:52 GMT Subject: RFR: 8353185: Introduce the concept of upgradeable files in context of JEP 493 In-Reply-To: References: Message-ID: <7KF-NVpbEGSbZybxLYZT2vZ0NYnqnjw2Zgx8mfkNPP4=.352e951b-23b5-47f8-ba22-c67ec7b173fe@github.com> On Thu, 3 Apr 2025 06:12:35 GMT, Bernd wrote: > What about changes to conf files, especially Java.security (for hardening TLS settings) - or at least pointing to a include? The opposite is where weaker or insecure algorithms are enabled, wouldn't want that copied by jlink into another run-time image. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2774625849 From duke at openjdk.org Thu Apr 3 06:48:52 2025 From: duke at openjdk.org (Bernd) Date: Thu, 3 Apr 2025 06:48:52 GMT Subject: RFR: 8353185: Introduce the concept of upgradeable files in context of JEP 493 In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 18:39:57 GMT, Severin Gehwolf wrote: > For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool. > > When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows: > > 1. The list of upgradeable files is hard-coded to `lib/tzdb.dat` and `lib/security/cacerts`. Only those two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image. > 2. The upgrade needs to be opt-in. Similar to `--ignore-signing-information` for signed modular JARs. A user needs to add `--upgrade-files=/` for it to succeed. > > `--upgrade-files` is a hidden `jlink` option since it only does anything for JEP 493 enabled builds. Users get a hint to apply the option if they so desire: > > Example: > > > $ ./bin/jlink --add-modules java.base --output java.base-jdk > Error: [..]/lib/security/cacerts has been modified > Hint: lib/security/cacerts is an upgradeable file. Add --upgrade-files=java.base/lib/security/cacerts to allow the upgrade. > > > using the hint we get: > > > $ ./bin/jlink --add-modules java.base --output java.base-jdk --upgrade-files=java.base/lib/security/cacerts > $ ./java.base-jdk/bin/java --list-modules > java.base at 25-internal > $ sha512sum ./java.base-jdk/lib/security/cacerts > cf2b4c17161e79001c8e07def3de36c0d523f00a2a6b6e33893a2a3669d930957c11ac765dd29d5ff80e63ad100ef0258291891377f7133b997111ba97b15146 ./java.base-jdk/lib/security/cacerts > $ sha512sum ./lib/security/cacerts > cf2b4c17161e79001c8e07def3de36c0d523f00a2a6b6e33893a2a3669d930957c11ac765dd29d5ff80e63ad100ef0258291891377f7133b997111ba97b15146 ./lib/security/cacerts > > > **Testing** > > - [ ] GHA > - [x] `jdk/tools/jlink` jtreg tests > - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files. > > Thoughts? Well, shipping customized runtimes sounds like a valid usecase, but yes maybe it?s more important for jpackage. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2774651205 From dholmes at openjdk.org Thu Apr 3 07:52:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 3 Apr 2025 07:52:54 GMT Subject: RFR: 8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH In-Reply-To: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> Message-ID: On Tue, 1 Apr 2025 09:13:45 GMT, Joachim Kern wrote: > In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so. > > The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed. Yes this was related to JRE but was changed to JDK by JDK-8343040. It does appear to be trying to find the upper lib directory in: JAVA_HOME/bin given the JRE location. Hence it is meaningless (and potentially "dangerous"!) when given the JDK/JAVA_HOME location ------------- PR Comment: https://git.openjdk.org/jdk/pull/24351#issuecomment-2774778621 From alan.bateman at oracle.com Thu Apr 3 08:17:34 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Thu, 3 Apr 2025 09:17:34 +0100 Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream In-Reply-To: References: <8721e7784793451187c5b6099eb37756@amazon.com> <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu> <8d453b79099b4675bce7f3902e3cd74f@amazon.com> <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com> Message-ID: <146bdb36-07bb-4bd9-8394-f5db20d6e4e9@oracle.com> On 02/04/2025 19:04, Engebretson, John wrote: > > ? Apologies, human error ? here?s the message I intended: > > ? Thank you!? I?ve updated the PR accordingly and summarized the > benchmarks in the description.? Here?s the short version: > > * For small payloads, unsynchronized and optimized versions are 2-4x > faster than base > * For large payloads, optimized version is 3x faster than base or > unsynchronized > > ? I discovered a capacity-related incompatibility between > ByteArrayOutputStream and MemoryOutputStream: the size() method > returns int, but MemoryOutputStream can exceed that value.? I added > range checking to size() and a new sizeAsLong() method? but it really > makes me wonder MemoryOutputStream belongs as a subclass of > ByteArrayOutputStream.? It now has two significant incompatibilities: > ignoring the protected fields, and size restrictions. > The protected fields are only accessible to subclasses so it's not an issue. BAOS::toByteArray (in addition to size) means the entire content must fit into a byte[]. A sink capable of accumulating but bytes that this is a different API. I think we should at least pursue ByteArrayOutputStream.unsynchronized(int cap) and work through the javadoc changes to allow that. It does not need to use buf, we have flexibility on how the bytes are buffered. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From pminborg at openjdk.org Thu Apr 3 08:20:52 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 08:20:52 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v34] In-Reply-To: References: Message-ID: > Implement JEP 502. > > The PR passes tier1-tier3 tests. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Address doc comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23972/files - new: https://git.openjdk.org/jdk/pull/23972/files/5dbcd4d0..56d9b3c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=33 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=32-33 Stats: 19 lines in 2 files changed: 17 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 PR: https://git.openjdk.org/jdk/pull/23972 From pminborg at openjdk.org Thu Apr 3 08:20:53 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 08:20:53 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: <8TWvYiVBfVx7hkRsn3Eo1WdyQWvhQFZ1mJzZfpZdIHQ=.6f67f77a-6ee9-4813-bd1f-57cc0d7fd0d7@github.com> On Wed, 2 Apr 2025 14:04:52 GMT, Alan Bateman wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Add info that Map#values and Map#entrySet are stable > > src/java.base/share/classes/java/lang/StableValue.java line 649: > >> 647: * be thrown. >> 648: * >> 649: * @param inputs the set of (non-null) allowed input values > > You might get asked what the behavior is when the inputs set contains the null element. Nice catch. The docs only state that if any _parameter_ is `null`, an NPE is thrown. I've fixed this now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026455401 From pminborg at openjdk.org Thu Apr 3 08:26:12 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 08:26:12 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: <4nLcumfsB_JNPi8xU5DZnorZvhllSjUz-zfop_CXXx8=.7122f5cf-6f22-4cc1-ba3e-cb57ade07e53@github.com> Message-ID: On Wed, 2 Apr 2025 21:37:25 GMT, Maurizio Cimadamore wrote: >> Or "observably immutable"? ? > > or... "immutable" There is a problem here: If we say it is "immutable content" people might think that passing mutable data makes it immutable. If we say it is "shallowly immutable content" people might think they cannot pass immutable data. I am not so sure that the term "effectively immutable" is widely understood. Another alternative is to rephrase entirely and say something like "A stable value is a holder of content that can be lazily computed at most once" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026464916 From pminborg at openjdk.org Thu Apr 3 08:39:17 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 08:39:17 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 14:24:04 GMT, Viktor Klang wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Add info that Map#values and Map#entrySet are stable > > src/java.base/share/classes/java/lang/StableValue.java line 374: > >> 372: * If there are circular dependencies in a dependency graph, a stable value will >> 373: * eventually throw a {@linkplain StackOverflowError} upon referencing elements in >> 374: * a circularity. > > Is this still correct, I thought it detected reentrancy? Good catch! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026488000 From pminborg at openjdk.org Thu Apr 3 08:43:15 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 08:43:15 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: <3arhaBIc5A-NbGpFZ_ehEMQhTzXSeIlel9cFNWwg9gE=.a1f457a0-ed07-4016-82ea-bace156ff4e9@github.com> On Wed, 2 Apr 2025 14:24:20 GMT, Viktor Klang wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Add info that Map#values and Map#entrySet are stable > > src/java.base/share/classes/java/lang/StableValue.java line 377: > >> 375: * >> 376: *

Thread Safety

>> 377: * The content of a stable value is guaranteed to be set at most once. If competing > > Suggestion: > > * The contents of a stable value is guaranteed to be set at most once. If competing I think it should be "content" as only one element can be set? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026493761 From dfuchs at openjdk.org Thu Apr 3 08:46:10 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 3 Apr 2025 08:46:10 GMT Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method [v13] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 21:59:32 GMT, David Beaumont wrote: >> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method. >> >> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package. >> 2. Add explanatory comments to various affected methods. >> 3. Add a test to ensure deadlocks no longer occur. >> >> Note that this change does not address issue in MemoryHandler (see JDK-8349208). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Tweak wording. LGTM ; Maybe give some time to @stuart-marks to have a look too. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23491#pullrequestreview-2738993076 From pminborg at openjdk.org Thu Apr 3 08:46:13 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 08:46:13 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 14:25:45 GMT, Viktor Klang wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Add info that Map#values and Map#entrySet are stable > > src/java.base/share/classes/java/lang/StableValue.java line 384: > >> 382: * (e.g. {@linkplain #trySet(Object) trySet()}) >> 383: * {@linkplain java.util.concurrent##MemoryVisibility happens-before} >> 384: * any subsequent read operation (e.g. {@linkplain #orElseThrow()}) that is successful. > > Suggestion: > > * any successful read operation (e.g. {@linkplain #orElseThrow()}). A read operation that is made well before a write operation does mean the write operation happens before the read operation so I wanted to capture that using the work "subsequent". Did I miss something here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026500380 From sgehwolf at openjdk.org Thu Apr 3 08:46:53 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 3 Apr 2025 08:46:53 GMT Subject: RFR: 8353185: Introduce the concept of upgradeable files in context of JEP 493 In-Reply-To: <7KF-NVpbEGSbZybxLYZT2vZ0NYnqnjw2Zgx8mfkNPP4=.352e951b-23b5-47f8-ba22-c67ec7b173fe@github.com> References: <7KF-NVpbEGSbZybxLYZT2vZ0NYnqnjw2Zgx8mfkNPP4=.352e951b-23b5-47f8-ba22-c67ec7b173fe@github.com> Message-ID: On Thu, 3 Apr 2025 06:31:20 GMT, Alan Bateman wrote: > What about changes to conf files, especially Java.security (for hardening TLS settings) - or at least pointing to a include? You can still do that after creating the custom runtime as you do today when linking using JMODs. The point of this fix is to be able to have a way to still run `jlink` based on the run-time image when you're using cacerts file from an external location (outside the JDKs control) or have updated tzdata (also outside the JDK build). I wouldn't expect for this to be needed in many (most?) cases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2774916530 From pminborg at openjdk.org Thu Apr 3 08:52:15 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 08:52:15 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 14:42:17 GMT, Viktor Klang wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Add info that Map#values and Map#entrySet are stable > > src/java.base/share/classes/java/lang/StableValue.java line 567: > >> 565: *

>> 566: * The provided {@code original} supplier is guaranteed to be successfully invoked >> 567: * at most once even in a multi-threaded environment. Competing threads invoking the > > There's a bit of a mix of "at most once" and "at-most-once". I'm fine with either but I prefer uniformity in spelling :) If "at most once" is an adjective then it should be spelled with dashes, otherwise not. "The method can be invoked at most once and hence It is an invoke-at-most-once method" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026509600 From ihse at openjdk.org Thu Apr 3 09:01:57 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 3 Apr 2025 09:01:57 GMT Subject: RFR: 8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH In-Reply-To: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> Message-ID: On Tue, 1 Apr 2025 09:13:45 GMT, Joachim Kern wrote: > In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so. > > The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed. Marked as reviewed by ihse (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24351#pullrequestreview-2739039686 From duke at openjdk.org Thu Apr 3 09:13:00 2025 From: duke at openjdk.org (tison) Date: Thu, 3 Apr 2025 09:13:00 GMT Subject: RFR: 8304674: AttachCurrentThread 's argument is JavaVMAttachArgs In-Reply-To: References: Message-ID: On Wed, 23 Oct 2024 06:06:43 GMT, tison wrote: > Try to add clear type annotations. > > Please let me know how this patch can be properly reviewed >_< > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [core-libs-dev](mailto:core-libs-dev at mail.openjdk.org):_ > > Hi, > > This change was already proposed (by myself): > > https://bugs.openjdk.org/browse/JDK-8289253 > > but it cannot be done as it will break source compatibility. > > We will just have to live with this historical oddity. > > Cheers, David > > On 31/03/2025 12:46 pm, tison wrote: Thanks for your information. Then closed as won't do. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21658#issuecomment-2774993075 From duke at openjdk.org Thu Apr 3 09:13:01 2025 From: duke at openjdk.org (tison) Date: Thu, 3 Apr 2025 09:13:01 GMT Subject: RFR: 8304674: AttachCurrentThread 's argument is JavaVMAttachArgs In-Reply-To: <7it4FHcVaDI_yWSKbTWO_ZQKhFfpy4AjpzN7bsYSRbo=.8920c59f-4189-4362-82c4-3f538c6a7e22@github.com> References: <7it4FHcVaDI_yWSKbTWO_ZQKhFfpy4AjpzN7bsYSRbo=.8920c59f-4189-4362-82c4-3f538c6a7e22@github.com> Message-ID: On Tue, 1 Apr 2025 05:38:17 GMT, Jaikiran Pai wrote: >> @jaikiran not yet. How can I create an issue for this PR? I don't find some instructions :/ > > Hello @tisonkun, > >> How can I create an issue for this PR? I don't find some instructions :/ > > In general, the OpenJDK contribution guide has these details https://openjdk.org/guide/. Typically, depending on the change, you either raise an issue through https://bugreport.java.com/bugreport/ or you create a discussion in the relevant mailing list. A PR is usually created after there's some consensus about the necessity of the change. > > For the current PR, David notes that this change was previously discussed and it was decided not to pursue further. If you have further questions or need additional inputs, I recommend that you subscribe to the hotspot-runtime-dev mailing list https://mail.openjdk.org/mailman/listinfo/hotspot-runtime-dev and create a discussion there. @jaikiran Thank you! I'll use this info if I make any other patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21658#issuecomment-2774993857 From duke at openjdk.org Thu Apr 3 09:13:01 2025 From: duke at openjdk.org (tison) Date: Thu, 3 Apr 2025 09:13:01 GMT Subject: Withdrawn: 8304674: AttachCurrentThread 's argument is JavaVMAttachArgs In-Reply-To: References: Message-ID: On Wed, 23 Oct 2024 06:06:43 GMT, tison wrote: > Try to add clear type annotations. > > Please let me know how this patch can be properly reviewed >_< This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/21658 From pminborg at openjdk.org Thu Apr 3 09:18:05 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 09:18:05 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 15:24:47 GMT, Viktor Klang wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Add info that Map#values and Map#entrySet are stable > > src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 115: > >> 113: >> 114: final int size = max - min + 1; >> 115: final Class enumType = (Class)inputs.iterator().next().getClass(); > > I presume there's some external check to ensure that inputs is non-empty? Yes. If empty, a normal `StableFunction` is provided even though an empty enum set was given. > src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 93: > >> 91: if (!trySet(content)) { >> 92: throw new IllegalStateException("Cannot set the content to " + content + >> 93: " because the content is already set: " + orElseThrow()); > > This might be problematic since it could surface confidential information inside exception messages (or even just produce very large strings). Good comment. Let's remove the content exposure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026554049 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026555389 From pminborg at openjdk.org Thu Apr 3 09:22:08 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 09:22:08 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 16:31:03 GMT, Viktor Klang wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Add info that Map#values and Map#entrySet are stable > > src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 125: > >> 123: Objects.requireNonNull(supplier); >> 124: final Object t = wrappedContentAcquire(); >> 125: return (t == null) ? orElseSetSlowPath(supplier) : unwrap(t); > > Is it faster to have the slow path on the true-case? I try to use non-negated conditions for clarity but have not checked any potential performance implications. Maybe we could investigate that after integration. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026563104 From pminborg at openjdk.org Thu Apr 3 09:28:10 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 09:28:10 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: <906RxEfLBFMhX7zur0MPRiBhP5IyHrsSrbF6Fl56WrE=.9606ce29-003c-425d-8abe-c77caaa41cda@github.com> On Wed, 2 Apr 2025 18:29:06 GMT, Viktor Klang wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Add info that Map#values and Map#entrySet are stable > > test/jdk/java/lang/StableValue/StableFunctionTest.java line 86: > >> 84: basic(inputs, MAPPER); >> 85: basic(inputs, _ -> null); >> 86: } > > Test for null mapper? There is a test where a `null` mapper is provided under the `factoryInvariants` test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026575292 From pminborg at openjdk.org Thu Apr 3 09:46:12 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 09:46:12 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 18:33:22 GMT, Viktor Klang wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Add info that Map#values and Map#entrySet are stable > > test/jdk/java/lang/StableValue/StableFunctionTest.java line 136: > >> 134: assertTrue(cached.toString().contains(Value.THIRTEEN + "=.unset")); >> 135: assertTrue(cached.toString().contains(Value.FORTY_TWO + "=.unset"), cached.toString()); >> 136: assertTrue(cached.toString().endsWith("}")); > > Not possible to test full toString() representation? The order in which mappings appear is unspecified, unfortunately. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026610510 From alanb at openjdk.org Thu Apr 3 09:48:55 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 3 Apr 2025 09:48:55 GMT Subject: RFR: 8353185: Introduce the concept of upgradeable files in context of JEP 493 In-Reply-To: References: Message-ID: <9QVEBGTFqMGaocyisN_zUY9mqQtC3mnJoazB0TH0yqU=.6035d751-84b5-4aa3-baf5-e2d02f692565@github.com> On Wed, 2 Apr 2025 18:39:57 GMT, Severin Gehwolf wrote: > For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool. > > When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows: > > 1. The list of upgradeable files is hard-coded to `lib/tzdb.dat` and `lib/security/cacerts`. Only those two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image. > 2. The upgrade needs to be opt-in. Similar to `--ignore-signing-information` for signed modular JARs. A user needs to add `--upgrade-files=/` for it to succeed. > > `--upgrade-files` is a hidden `jlink` option since it only does anything for JEP 493 enabled builds. Users get a hint to apply the option if they so desire: > > Example: > > > $ ./bin/jlink --add-modules java.base --output java.base-jdk > Error: [..]/lib/security/cacerts has been modified > Hint: lib/security/cacerts is an upgradeable file. Add --upgrade-files=java.base/lib/security/cacerts to allow the upgrade. > > > using the hint we get: > > > $ ./bin/jlink --add-modules java.base --output java.base-jdk --upgrade-files=java.base/lib/security/cacerts > $ ./java.base-jdk/bin/java --list-modules > java.base at 25-internal > $ sha512sum ./java.base-jdk/lib/security/cacerts > cf2b4c17161e79001c8e07def3de36c0d523f00a2a6b6e33893a2a3669d930957c11ac765dd29d5ff80e63ad100ef0258291891377f7133b997111ba97b15146 ./java.base-jdk/lib/security/cacerts > $ sha512sum ./lib/security/cacerts > cf2b4c17161e79001c8e07def3de36c0d523f00a2a6b6e33893a2a3669d930957c11ac765dd29d5ff80e63ad100ef0258291891377f7133b997111ba97b15146 ./lib/security/cacerts > > > **Testing** > > - [x] GHA > - [x] `jdk/tools/jlink` jtreg tests > - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files. > > Thoughts? Part of me is concerned that the hidden option is a bit of an attractive nuisance. What would you think about just having a fixed list in a properties file in the repo, thus a resource in the jlink module. This would avoid the list in JRTArchive too. It wouldn't rule out introducing something more in the future. Right now the only examples we have are in java.base. In time it might be that some other modules might need something. I've like to know more about cacerts. Are the distros swapping this to a link after the run-time image is created or is it that the sym link is there from the startup and the hashing has followed the link? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2775120209 From vklang at openjdk.org Thu Apr 3 09:51:15 2025 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 3 Apr 2025 09:51:15 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: <3arhaBIc5A-NbGpFZ_ehEMQhTzXSeIlel9cFNWwg9gE=.a1f457a0-ed07-4016-82ea-bace156ff4e9@github.com> References: <3arhaBIc5A-NbGpFZ_ehEMQhTzXSeIlel9cFNWwg9gE=.a1f457a0-ed07-4016-82ea-bace156ff4e9@github.com> Message-ID: On Thu, 3 Apr 2025 08:39:47 GMT, Per Minborg wrote: >> src/java.base/share/classes/java/lang/StableValue.java line 377: >> >>> 375: * >>> 376: *

Thread Safety

>>> 377: * The content of a stable value is guaranteed to be set at most once. If competing >> >> Suggestion: >> >> * The contents of a stable value is guaranteed to be set at most once. If competing > > I think it should be "content" as only one element can be set? I'm definitely not an expert here, so I'll defer to someone more knowledgable :) >> src/java.base/share/classes/java/lang/StableValue.java line 384: >> >>> 382: * (e.g. {@linkplain #trySet(Object) trySet()}) >>> 383: * {@linkplain java.util.concurrent##MemoryVisibility happens-before} >>> 384: * any subsequent read operation (e.g. {@linkplain #orElseThrow()}) that is successful. >> >> Suggestion: >> >> * any successful read operation (e.g. {@linkplain #orElseThrow()}). > > A read operation that is made well before a write operation does mean the write operation happens before the read operation so I wanted to capture that using the work "subsequent". Did I miss something here? I just thought it awkward to establish order (happens-before) by using a word like "subsequent" (which implies order). >> src/java.base/share/classes/java/lang/StableValue.java line 567: >> >>> 565: *

>>> 566: * The provided {@code original} supplier is guaranteed to be successfully invoked >>> 567: * at most once even in a multi-threaded environment. Competing threads invoking the >> >> There's a bit of a mix of "at most once" and "at-most-once". I'm fine with either but I prefer uniformity in spelling :) > > If "at most once" is an adjective then it should be spelled with dashes, otherwise not. > > "The method can be invoked at most once and hence It is an invoke-at-most-once method" That sounds fair! ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026617309 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026619405 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026620361 From pminborg at openjdk.org Thu Apr 3 09:51:15 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 09:51:15 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 18:33:39 GMT, Viktor Klang wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Add info that Map#values and Map#entrySet are stable > > test/jdk/java/lang/StableValue/StableFunctionTest.java line 147: > >> 145: cached.apply(Value.FORTY_TWO); >> 146: String toString = cached.toString(); >> 147: assertTrue(toString.contains("(this StableFunction)"), toString); > > Not possible to test full toString() representation? The order is unspecified but the test could be improved to cover the key associated as well. I will add that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026615845 From sgehwolf at openjdk.org Thu Apr 3 10:27:47 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 3 Apr 2025 10:27:47 GMT Subject: RFR: 8353185: Introduce the concept of upgradeable files in context of JEP 493 In-Reply-To: <9QVEBGTFqMGaocyisN_zUY9mqQtC3mnJoazB0TH0yqU=.6035d751-84b5-4aa3-baf5-e2d02f692565@github.com> References: <9QVEBGTFqMGaocyisN_zUY9mqQtC3mnJoazB0TH0yqU=.6035d751-84b5-4aa3-baf5-e2d02f692565@github.com> Message-ID: <_mC3xJvbf0K_Bb4ywZIMUzDFiUzs70vIZz48z43R5-k=.3c8e049b-a869-4cfa-9623-c30ffea6c549@github.com> On Thu, 3 Apr 2025 09:46:38 GMT, Alan Bateman wrote: > Part of me is concerned that the hidden option is a bit of an attractive nuisance. What would you think about just having a fixed list in a properties file in the repo, thus a resource in the jlink module. This would avoid the list in JRTArchive too. It wouldn't rule out introducing something more in the future. I'm not entirely sure what you are suggesting. Is it keeping a list of "upgradeable" files in a properties file. Files listed in that properties file aren't checked for hash sums (i.e. even if it's not modified)? That is, the explicit opt-in is not needed? Fine by me, but it's a weaker check. If we don't need the explicit opt-in, the patch becomes simpler as well. > Right now the only examples we have are in java.base. In time it might be that some other modules might need something. Sure. I've considered that. The `java.base` specific check can go away and it should work for any module as long as we have a list of what's considered an upgradable file (wherever it comes from). > I've like to know more about cacerts. Are the distros swapping this to a link after the run-time image is created or is it that the sym link is there from the startup and the hashing has followed the link? Yes, that's one case. For example Fedora/RHEL distros have a `ca-certificates` package which also provides a `cacerts` file consumable from the JDK (`/etc/pki/java/cacerts`). This can be a build-time option, or replaced with a symlink after the JDK has been built. Another use case is amending the cacerts store. For example with an enterprise internal CA, in a container. It's really not different to `tzdb.dat`. That too, can be a symlink to a system package or get updated with an external tool after a build. The option of not following symlinks, isn't an option, though, as certain distro packaging standards require one to install, say man pages - in a specific directory. To keep the JDK image whole, that is usually fixed by placing a symlink back in the JDK image directory. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2775258217 From pminborg at openjdk.org Thu Apr 3 10:43:14 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 10:43:14 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 18:42:06 GMT, Viktor Klang wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Add info that Map#values and Map#entrySet are stable > > test/jdk/java/lang/StableValue/StableMapTest.java line 143: > >> 141: assertTrue(actual.contains(key + "=.unset")); >> 142: } >> 143: assertTrue(actual.endsWith("}")); > > I guess the problem here is that the order of a map is not deterministic? Yes, that is the problem. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026722198 From pminborg at openjdk.org Thu Apr 3 10:49:16 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 10:49:16 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 18:46:06 GMT, Viktor Klang wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Add info that Map#values and Map#entrySet are stable > > test/jdk/java/lang/StableValue/StableValueFactoriesTest.java line 36: > >> 34: import static org.junit.jupiter.api.Assertions.*; >> 35: >> 36: final class StableValueFactoriesTest { > > Just confirming?this is all that needs testing here? I've removed most methods from the factories and referenced implementations directly. So, only one method remains here. However, it might be the case that I need to resurrect some of the methods here as we progress in using stable values internally in the JDK (as StableValue is a preview feature but the underlying implementations are not). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026732065 From pminborg at openjdk.org Thu Apr 3 10:56:27 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 10:56:27 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 18:49:31 GMT, Viktor Klang wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Add info that Map#values and Map#entrySet are stable > > test/jdk/java/lang/StableValue/StableValueTest.java line 262: > >> 260: threads.forEach(StableValueTest::join); >> 261: // There can only be one winner >> 262: assertEquals(1, winner.cardinality()); > > AFAIK BitSet is not thread safe, so you have multiple threads writing to it?which may or may not provide the right guarantees to lean on for this test. Might be better to lean on CHM. Nice catch. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026740369 From pminborg at openjdk.org Thu Apr 3 11:17:44 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 11:17:44 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v35] In-Reply-To: References: Message-ID: <7rebkk0Yd_shYsWWPbfnpVXaYfv9jZhorLSoSc9bVmI=.5678c589-0524-45f3-ae38-6060c1bcc0b0@github.com> > Implement JEP 502. > > The PR passes tier1-tier3 tests. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Address comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23972/files - new: https://git.openjdk.org/jdk/pull/23972/files/56d9b3c0..96a90d0f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=34 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=33-34 Stats: 153 lines in 12 files changed: 44 ins; 20 del; 89 mod Patch: https://git.openjdk.org/jdk/pull/23972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 PR: https://git.openjdk.org/jdk/pull/23972 From pminborg at openjdk.org Thu Apr 3 11:17:46 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 11:17:46 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 14:30:05 GMT, Viktor Klang wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Add info that Map#values and Map#entrySet are stable > > src/java.base/share/classes/java/lang/StableValue.java line 426: > >> 424: * {@linkplain java.lang.ref##reachability strongly reachable}. Clients are >> 425: * advised that {@linkplain java.lang.ref##reachability reachable} stable values >> 426: * will hold their set content perpetually. > > This reads like the contents of StableValues will never be garbage collected, even if the StableValue is no longer reachable. Is that intended? I've changed the wording now so it becomes clearer that the content can be GCed when the SV gets GCed. > src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 191: > >> 189: @ForceInline >> 190: private static Object wrap(Object t) { >> 191: return (t == null) ? NULL_SENTINEL : t; > > Personal preference, but it would seem more consistent to do the same check in wrap as in unwrap: > > Suggestion: > > return (t != null) ? t : NULL_SENTINEL; I've changed the unwrap method... > test/jdk/java/lang/StableValue/StableValuesSafePublicationTest.java line 64: > >> 62: // fully initialized thanks to the HB properties of StableValue. >> 63: int a; >> 64: int b; > > Might be worth putting in some more fields to increase the chance of detecting a mismatch. Good idea! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026777162 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026775227 PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026769897 From per-ake.minborg at oracle.com Thu Apr 3 11:20:37 2025 From: per-ake.minborg at oracle.com (Per-Ake Minborg) Date: Thu, 3 Apr 2025 11:20:37 +0000 Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) In-Reply-To: <1257824626.204034517.1743604437041.JavaMail.zimbra@univ-eiffel.fr> References: <1257824626.204034517.1743604437041.JavaMail.zimbra@univ-eiffel.fr> Message-ID: Hi Remi and thank you for the feedback from JChateau (what a wonderful name!). This is one of the issues we already have on the list for the next round of preview. Now we know more folks are on the same page. Best, Per ________________________________ From: Remi Forax Sent: Wednesday, April 2, 2025 4:33 PM To: Per Minborg Cc: compiler-dev ; core-libs-dev ; hotspot-dev ; security-dev Subject: Re: RFR: 8351565: Implement JEP 502: Stable Values (Preview) Hi Per, last week, at JChateau, we had a one hour session about stable values, I've build the JDK with this PR so we can discuss about it. To present the API, i start from the double check locking, rewriting it to use the StableValue API. The main remark was that methods like orElseSet() or isSet() are hard to used correctly. In my opinion, the current API is a mix of a high level API and a low-level API but it's too easy to misuse the low-level API. high level: - methods supplier(), list() and map() Those are easy to use low level: - methods: of, of(value), orElseSet, setOrThrow(), etc Those are hard to use properly. I think, not necessary in this PR, that the current API should be separated into two different classes, one in java.lang with the high level API (the static methods other than Of() and one in java.util.concurrent with the low level API where you have to know what you are doing (like with any classes of java.util.concurrent). regards, R?mi ----- Original Message ----- > From: "Per Minborg" > To: "compiler-dev" , "core-libs-dev" , "hotspot-dev" > , "security-dev" > Sent: Thursday, March 13, 2025 12:20:10 PM > Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) > Implement JEP 502. > > The PR passes tier1-tier3 tests. > > ------------- > > Commit messages: > - Use acquire semantics for reading rather than volatile semantics > - Add missing null check > - Simplify handling of sentinel, wrap, and unwrap > - Fix JavaDoc issues > - Fix members in StableEnumFunction > - Address some comments in the PR > - Merge branch 'master' into implement-jep502 > - Revert change > - Fix copyright issues > - Update JEP number > - ... and 231 more: https://git.openjdk.org/jdk/compare/4cf63160...09ca44e6 > > Changes: https://git.openjdk.org/jdk/pull/23972/files > Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=00 > Issue: https://bugs.openjdk.org/browse/JDK-8351565 > Stats: 3980 lines in 30 files changed: 3949 ins; 18 del; 13 mod > Patch: https://git.openjdk.org/jdk/pull/23972.diff > Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 > > PR: https://git.openjdk.org/jdk/pull/23972 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pminborg at openjdk.org Thu Apr 3 11:26:20 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 11:26:20 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v27] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 14:58:35 GMT, Maurizio Cimadamore wrote: >> There are two fundamental variants. One with `CACHED_SIZE` (for list and int function) and one with `CACHED_KEYS` (for map and function). > > Yes - but they cache different things -- the first caches results for values 0-9 -- the second cached results for 1, 2, 4, 8, 16, 32. That was intentional as the list is always `0..size` whereas a map can use arbitrary inputs. Is there a better way to illustrate this than what we have now? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026797215 From pminborg at openjdk.org Thu Apr 3 11:34:03 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 11:34:03 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v36] In-Reply-To: References: Message-ID: <3opJVhWPrXB0R9O-EL6Zd_VOTQT7GuzTIR_hKrfhIms=.fbb9b437-a6b4-4e5d-99ee-88fe8b83ca7f@github.com> > Implement JEP 502. > > The PR passes tier1-tier3 tests. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Move Serializable specs to @implNote ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23972/files - new: https://git.openjdk.org/jdk/pull/23972/files/96a90d0f..63f88544 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=35 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=34-35 Stats: 17 lines in 1 file changed: 1 ins; 10 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/23972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 PR: https://git.openjdk.org/jdk/pull/23972 From jpai at openjdk.org Thu Apr 3 11:40:23 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 3 Apr 2025 11:40:23 GMT Subject: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v8] In-Reply-To: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> Message-ID: > Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes? > > As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`. > > The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes. > > I'll draft a CSR once we agree on the proposed text. 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 16 additional commits since the last revision: - additional inputs - merge latest from master branch - Alan's input - replace "@apiNote" in favour of formal spec - merge latest from master branch - Lance's inputs - merge latest from master branch - merge latest from master branch - merge latest from master branch - additional updates to the doc - merge latest from master branch - ... and 6 more: https://git.openjdk.org/jdk/compare/803443c7...cfeef86d ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23655/files - new: https://git.openjdk.org/jdk/pull/23655/files/f2d08bad..cfeef86d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23655&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23655&range=06-07 Stats: 5880 lines in 369 files changed: 3265 ins; 2002 del; 613 mod Patch: https://git.openjdk.org/jdk/pull/23655.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23655/head:pull/23655 PR: https://git.openjdk.org/jdk/pull/23655 From jpai at openjdk.org Thu Apr 3 11:40:25 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 3 Apr 2025 11:40:25 GMT Subject: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v7] In-Reply-To: References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> Message-ID: <3yxnAvXDwjdh3cj_t2kguU7llkdP0lKVP8g-t9DN04I=.0b4f8fe4-ebde-4719-bc49-f4605f90f357@github.com> On Tue, 1 Apr 2025 07:22:45 GMT, Jaikiran Pai wrote: >> Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`. >> >> The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes. >> >> I'll draft a CSR once we agree on the proposed text. > > 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 14 additional commits since the last revision: > > - Alan's input - replace "@apiNote" in favour of formal spec > - merge latest from master branch > - Lance's inputs > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - additional updates to the doc > - merge latest from master branch > - change "@implSpec" to "@apiNote" and update their text > - add class level documentation > - ... and 4 more: https://git.openjdk.org/jdk/compare/a96c2ed0...f2d08bad With help from Alan and Lance, we went over the text one more time and I've now updated the PR with a version that we think captures the necessary details. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23655#issuecomment-2775476064 From alanb at openjdk.org Thu Apr 3 12:09:57 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 3 Apr 2025 12:09:57 GMT Subject: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v8] In-Reply-To: References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> Message-ID: On Thu, 3 Apr 2025 11:40:23 GMT, Jaikiran Pai wrote: >> Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`. >> >> The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes. >> >> I'll draft a CSR once we agree on the proposed text. > > 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 16 additional commits since the last revision: > > - additional inputs > - merge latest from master branch > - Alan's input - replace "@apiNote" in favour of formal spec > - merge latest from master branch > - Lance's inputs > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - additional updates to the doc > - merge latest from master branch > - ... and 6 more: https://git.openjdk.org/jdk/compare/9d89f79e...cfeef86d The wording is good, thanks for persisting through all the iterations to get this right. src/java.base/share/classes/java/util/zip/DeflaterInputStream.java line 38: > 36: * > 37: *

Compressor Usage

> 38: * A {@linkplain DeflaterInputStream} created without I don't think you meant to use @linkplain here, should be @code or @link. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23655#pullrequestreview-2739616795 PR Review Comment: https://git.openjdk.org/jdk/pull/23655#discussion_r2026860948 From mcimadamore at openjdk.org Thu Apr 3 12:10:13 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 3 Apr 2025 12:10:13 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: <4nLcumfsB_JNPi8xU5DZnorZvhllSjUz-zfop_CXXx8=.7122f5cf-6f22-4cc1-ba3e-cb57ade07e53@github.com> Message-ID: On Thu, 3 Apr 2025 08:22:47 GMT, Per Minborg wrote: > "A stable value is a holder of content that can be lazily computed at most once" I'd replace `computed` with `set` (as that's the term we use in the API). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026860656 From mcimadamore at openjdk.org Thu Apr 3 12:22:03 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 3 Apr 2025 12:22:03 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v27] In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 11:23:36 GMT, Per Minborg wrote: >> Yes - but they cache different things -- the first caches results for values 0-9 -- the second cached results for 1, 2, 4, 8, 16, 32. > > That was intentional as the list is always `0..size` whereas a map can use arbitrary inputs. Is there a better way to illustrate this than what we have now? I guess my "beef" is that the examples for int function and function are similar -- they use same class name. Reader might expect (as I did) that they do the same thing, just using a different backing storage. But they don't -- not only is the implementation tweaked to use function instead of int function -- also what is cached changes subtly. I'm afraid this will be difficult to follow for readers. If you want to highlight that the "function" example has more freedom, I think we'd be better off with using another example. For instance: * use square(int)->int to show off int function/list * use square_root(int)->int to show off function/map ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026872636 From mcimadamore at openjdk.org Thu Apr 3 12:22:03 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 3 Apr 2025 12:22:03 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v27] In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 12:14:52 GMT, Maurizio Cimadamore wrote: >> That was intentional as the list is always `0..size` whereas a map can use arbitrary inputs. Is there a better way to illustrate this than what we have now? > > I guess my "beef" is that the examples for int function and function are similar -- they use same class name. Reader might expect (as I did) that they do the same thing, just using a different backing storage. But they don't -- not only is the implementation tweaked to use function instead of int function -- also what is cached changes subtly. I'm afraid this will be difficult to follow for readers. If you want to highlight that the "function" example has more freedom, I think we'd be better off with using another example. For instance: > > * use square(int)->int to show off int function/list > * use square_root(int)->int to show off function/map (e.g. stable int function is good for _total functions_ -- stable function is good for _partial functions_) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026878559 From mcimadamore at openjdk.org Thu Apr 3 12:22:05 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 3 Apr 2025 12:22:05 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v36] In-Reply-To: <3opJVhWPrXB0R9O-EL6Zd_VOTQT7GuzTIR_hKrfhIms=.fbb9b437-a6b4-4e5d-99ee-88fe8b83ca7f@github.com> References: <3opJVhWPrXB0R9O-EL6Zd_VOTQT7GuzTIR_hKrfhIms=.fbb9b437-a6b4-4e5d-99ee-88fe8b83ca7f@github.com> Message-ID: <-H3A19LuNrURjLlvH7RqzUtn8qHz1ywC9xSDpMT2qmQ=.4646b6dd-1a7c-48fc-917c-eff7ef32571f@github.com> On Thu, 3 Apr 2025 11:34:03 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Move Serializable specs to @implNote src/java.base/share/classes/java/lang/StableValue.java line 653: > 651: * {@code null} element. > 652: */ > 653: static Function function(Set inputs, The javadoc should say that the returned function throws IAE if the input is not supported, right? An alternative would be to have a factory that returns `Function>` -- although that would be more cumbersome to use. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026875874 From pminborg at openjdk.org Thu Apr 3 12:45:05 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 12:45:05 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v37] In-Reply-To: References: Message-ID: > Implement JEP 502. > > The PR passes tier1-tier3 tests. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Break out and move performance related text ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23972/files - new: https://git.openjdk.org/jdk/pull/23972/files/63f88544..596bc131 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=36 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=35-36 Stats: 27 lines in 1 file changed: 13 ins; 9 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 PR: https://git.openjdk.org/jdk/pull/23972 From jengebr at amazon.com Thu Apr 3 12:45:04 2025 From: jengebr at amazon.com (Engebretson, John) Date: Thu, 3 Apr 2025 12:45:04 +0000 Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream In-Reply-To: <146bdb36-07bb-4bd9-8394-f5db20d6e4e9@oracle.com> References: <8721e7784793451187c5b6099eb37756@amazon.com> <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu> <8d453b79099b4675bce7f3902e3cd74f@amazon.com> <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com> <146bdb36-07bb-4bd9-8394-f5db20d6e4e9@oracle.com> Message-ID: <426eefbde9c946daaca00c9829d87c2b@amazon.com> I certainly see the value in the unsynchronized variant and am happy to do that ? but that isn?t sufficient to address the original problem of scaling the array. MemoryOutputStream results in 3x improvement and eliminates the hard 2GB cap, and can replace custom logic in Tomcat, Spring, etc. What?s our next move there? Thanks! ? John From: Alan Bateman Sent: Thursday, April 3, 2025 3:18 AM To: Engebretson, John ; Markus KARG ; core-libs-dev at openjdk.org Subject: RE: [EXTERNAL] JDK-8352891 Performance improvements to ByteArrayOutputStream CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On 02/04/2025 19:04, Engebretson, John wrote: Apologies, human error ? here?s the message I intended: Thank you! I?ve updated the PR accordingly and summarized the benchmarks in the description. Here?s the short version: 1. For small payloads, unsynchronized and optimized versions are 2-4x faster than base 2. For large payloads, optimized version is 3x faster than base or unsynchronized I discovered a capacity-related incompatibility between ByteArrayOutputStream and MemoryOutputStream: the size() method returns int, but MemoryOutputStream can exceed that value. I added range checking to size() and a new sizeAsLong() method? but it really makes me wonder MemoryOutputStream belongs as a subclass of ByteArrayOutputStream. It now has two significant incompatibilities: ignoring the protected fields, and size restrictions. The protected fields are only accessible to subclasses so it's not an issue. BAOS::toByteArray (in addition to size) means the entire content must fit into a byte[]. A sink capable of accumulating but bytes that this is a different API. I think we should at least pursue ByteArrayOutputStream.unsynchronized(int cap) and work through the javadoc changes to allow that. It does not need to use buf, we have flexibility on how the bytes are buffered. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From pminborg at openjdk.org Thu Apr 3 12:45:06 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 12:45:06 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v37] In-Reply-To: <8eLNHYCb3NOjDPJhbTd2sT_MxAhlPjI9fC4mr0sSWOU=.51260d3f-6585-4fbb-a367-43f26bc225fb@github.com> References: <8eLNHYCb3NOjDPJhbTd2sT_MxAhlPjI9fC4mr0sSWOU=.51260d3f-6585-4fbb-a367-43f26bc225fb@github.com> Message-ID: <7BWHGjMq2rjz8Zf2IEnooWjVeidLaur-BZ6HCEXb-3o=.f5850de2-b1e0-4d73-afca-4df5350f0900@github.com> On Wed, 12 Mar 2025 14:14:13 GMT, Per Minborg wrote: >> It's true that the storage can be flatter here -- that said, this can also be done as a later refactoring. One advantage of doing things the way @minborg did it here, is that it's fairly easy to prove that the code below is correct -- which makes the initial review easier. > > Ahh. Now I see what you mean. This is something we did in a handful of prototypes we explored. While it is true that there will be one indirection less, the complexity of the code is going to grow. Also, if the element is constant folded, it does not matter. We will explore this option after the first integration of Stable Values. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026914998 From jpai at openjdk.org Thu Apr 3 12:55:11 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 3 Apr 2025 12:55:11 GMT Subject: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v9] In-Reply-To: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> Message-ID: > Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes? > > As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`. > > The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes. > > I'll draft a CSR once we agree on the proposed text. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: @code instead of @linkplain ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23655/files - new: https://git.openjdk.org/jdk/pull/23655/files/cfeef86d..ae42a9e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23655&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23655&range=07-08 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23655.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23655/head:pull/23655 PR: https://git.openjdk.org/jdk/pull/23655 From jpai at openjdk.org Thu Apr 3 12:55:13 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 3 Apr 2025 12:55:13 GMT Subject: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v8] In-Reply-To: References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> Message-ID: On Thu, 3 Apr 2025 12:07:16 GMT, Alan Bateman 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 16 additional commits since the last revision: >> >> - additional inputs >> - merge latest from master branch >> - Alan's input - replace "@apiNote" in favour of formal spec >> - merge latest from master branch >> - Lance's inputs >> - merge latest from master branch >> - merge latest from master branch >> - merge latest from master branch >> - additional updates to the doc >> - merge latest from master branch >> - ... and 6 more: https://git.openjdk.org/jdk/compare/7c089963...cfeef86d > > src/java.base/share/classes/java/util/zip/DeflaterInputStream.java line 38: > >> 36: * >> 37: *

Compressor Usage

>> 38: * A {@linkplain DeflaterInputStream} created without > > I don't think you meant to use @linkplain here, should be @code or @link. That was meant to be `@code`. Fixed now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23655#discussion_r2026933587 From pminborg at openjdk.org Thu Apr 3 12:57:56 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 12:57:56 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v38] In-Reply-To: References: Message-ID: > Implement JEP 502. > > The PR passes tier1-tier3 tests. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Clean up StableValue docs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23972/files - new: https://git.openjdk.org/jdk/pull/23972/files/596bc131..8ec7ac01 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=37 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=36-37 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 PR: https://git.openjdk.org/jdk/pull/23972 From pminborg at openjdk.org Thu Apr 3 12:57:57 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 12:57:57 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 19:22:28 GMT, Quan Anh Mai wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Add info that Map#values and Map#entrySet are stable > > src/java.base/share/classes/java/lang/StableValue.java line 402: > >> 400: * race. Since stable functions and stable collections are built on top of >> 401: * {@linkplain StableValue#orElseSet(Supplier) orElseSet()} they too are >> 402: * thread safe and guarantee at-most-once-per-input invocation. > > Do we guarantee that there is a total order with respect to the suppliers that fail to return. You can take a look at the specification of [`std::call_once`](https://en.cppreference.com/w/cpp/thread/call_once) > >> All active calls on the same flag form a single total order consisting of zero or more exceptional calls, followed by one returning call. The end of each active call synchronizes-with the next active call in that order. >> The return from the returning call synchronizes-with the returns from all passive calls on the same flag: this means that all concurrent calls to std::call_once are guaranteed to observe any side-effects made by the active call, with no additional synchronization. I don't think we should promise this even though it might be the case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2026937625 From jpai at openjdk.org Thu Apr 3 12:59:49 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 3 Apr 2025 12:59:49 GMT Subject: RFR: 8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH In-Reply-To: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> Message-ID: <-jGUmaeX6LpbFkDH7euctBwxj4t-qEeMB0VPKPAdJmo=.b21af75f-f50b-4d20-9e3f-a2e29b83c07a@github.com> On Tue, 1 Apr 2025 09:13:45 GMT, Joachim Kern wrote: > In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so. > > The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed. Hello @JoKern65, the change looks reasonable to me. Please give me a day or so to run this change against our CI. In the meantime, could you please update the copyright years on `java_md.c` and the `Test7029048.java` files? ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24351#pullrequestreview-2739755041 From pminborg at openjdk.org Thu Apr 3 13:05:29 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 13:05:29 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v39] In-Reply-To: References: Message-ID: > Implement JEP 502. > > The PR passes tier1-tier3 tests. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Specify that an exception is thrown for illegal inputs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23972/files - new: https://git.openjdk.org/jdk/pull/23972/files/8ec7ac01..a83ec0e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=38 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=37-38 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 PR: https://git.openjdk.org/jdk/pull/23972 From jkern at openjdk.org Thu Apr 3 13:09:10 2025 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 3 Apr 2025 13:09:10 GMT Subject: RFR: 8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH [v2] In-Reply-To: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> Message-ID: > In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so. > > The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed. Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24351/files - new: https://git.openjdk.org/jdk/pull/24351/files/9d41d444..6f32ead9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24351&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24351&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24351.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24351/head:pull/24351 PR: https://git.openjdk.org/jdk/pull/24351 From jpai at openjdk.org Thu Apr 3 13:19:50 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 3 Apr 2025 13:19:50 GMT Subject: RFR: 8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH [v2] In-Reply-To: References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com> Message-ID: <1ZlVOX-syJsHCcWc4yTKeGaYofqbzGPSKOpTzq42xaU=.ff26b49e-397a-4012-aaad-b897adfaa8a2@github.com> On Thu, 3 Apr 2025 13:09:10 GMT, Joachim Kern wrote: >> In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so. >> >> The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > copyright years Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24351#pullrequestreview-2739814339 From lancea at openjdk.org Thu Apr 3 13:26:04 2025 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 3 Apr 2025 13:26:04 GMT Subject: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v9] In-Reply-To: References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> Message-ID: On Thu, 3 Apr 2025 12:55:11 GMT, Jaikiran Pai wrote: >> Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`. >> >> The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes. >> >> I'll draft a CSR once we agree on the proposed text. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > @code instead of @linkplain Looks good Jai. thank you for working through this ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23655#pullrequestreview-2739833121 From asemenyuk at openjdk.org Thu Apr 3 13:59:09 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 3 Apr 2025 13:59:09 GMT Subject: Integrated: 8352419: Test tools/jpackage/share/ErrorTest.java#id0 and #id1 fail In-Reply-To: <1QksvVOulgv5y1TaYzDy8SomeWoYrGp0WgOU4GhLpwk=.ae5739b3-4ca0-462b-b4d7-4e0d8480572f@github.com> References: <1QksvVOulgv5y1TaYzDy8SomeWoYrGp0WgOU4GhLpwk=.ae5739b3-4ca0-462b-b4d7-4e0d8480572f@github.com> Message-ID: <0DqCvedYImjFr2zz22XUV00VEr9rUKA4G3PHmR8itt8=.d26d2c53-63b7-462a-bfc6-fe606f821861@github.com> On Fri, 28 Mar 2025 15:02:05 GMT, Alexey Semenyuk wrote: > Make tools/jpackage/share/ErrorTest.java test safely handle the case when native bundling is unavailable on the test host. > > Additionally: > - If native bundling is unavailable on the test host, PackageTest will throw `jtreg.SkippedException` and mark the test as skipped instead of silently doing nothing. This should mark a few jpackage tests "skipped" in tests runs on Alpine Linux that doesn't support either .deb or .rpm packaging. > - Get rid of the dependency on `jtreg.SkippedException` from `/jdk/test` lib as this exception can be thrown from almost every jpackage test because of the changes in PackageTest. Instead embed `jtreg.SkippedException` classfile in TKit.java source and load it from there. This is a less intrusive alternative to adding > > * @library /test/lib > * @build jtreg.SkippedException > > in every jtreg test declaration This pull request has now been integrated. Changeset: 70e32500 Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/70e325004536eb9b79f4943f27eed4ac6cec8bd5 Stats: 180 lines in 6 files changed: 128 ins; 25 del; 27 mod 8352419: Test tools/jpackage/share/ErrorTest.java#id0 and #id1 fail Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/24294 From pminborg at openjdk.org Thu Apr 3 14:00:00 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 3 Apr 2025 14:00:00 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v40] In-Reply-To: References: Message-ID: <37CdPM7bEE8_OFcNuJfrGNmBAJPrw0yHNwGfry10wQI=.9c1394e3-6399-4e2d-8199-da5092bb6deb@github.com> > Implement JEP 502. > > The PR passes tier1-tier3 tests. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Make the sqrt example different ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23972/files - new: https://git.openjdk.org/jdk/pull/23972/files/a83ec0e7..c80452c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=39 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=38-39 Stats: 120 lines in 2 files changed: 79 ins; 7 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/23972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 PR: https://git.openjdk.org/jdk/pull/23972 From acobbs at openjdk.org Thu Apr 3 14:23:12 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 3 Apr 2025 14:23:12 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v40] In-Reply-To: <37CdPM7bEE8_OFcNuJfrGNmBAJPrw0yHNwGfry10wQI=.9c1394e3-6399-4e2d-8199-da5092bb6deb@github.com> References: <37CdPM7bEE8_OFcNuJfrGNmBAJPrw0yHNwGfry10wQI=.9c1394e3-6399-4e2d-8199-da5092bb6deb@github.com> Message-ID: On Thu, 3 Apr 2025 14:00:00 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Make the sqrt example different src/java.base/share/classes/java/lang/StableValue.java line 383: > 381: * (e.g. {@linkplain #trySet(Object) trySet()}) > 382: * {@linkplain java.util.concurrent##MemoryVisibility happens-before} > 383: * any subsequent read operation (e.g. {@linkplain #orElseThrow()}) that is successful. Is `isSet()` also considered to be a "read operation"? I would assume so, but that requires a bit of reading between the lines. Maybe `isSet()` could be added as another parenthetical example after `orElseThrow()` here to squash that particular ambiguity. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2027115078 From qamai at openjdk.org Thu Apr 3 14:31:12 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 3 Apr 2025 14:31:12 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33] In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 12:54:01 GMT, Per Minborg wrote: >> src/java.base/share/classes/java/lang/StableValue.java line 402: >> >>> 400: * race. Since stable functions and stable collections are built on top of >>> 401: * {@linkplain StableValue#orElseSet(Supplier) orElseSet()} they too are >>> 402: * thread safe and guarantee at-most-once-per-input invocation. >> >> Do we guarantee that there is a total order with respect to the suppliers that fail to return. You can take a look at the specification of [`std::call_once`](https://en.cppreference.com/w/cpp/thread/call_once) >> >>> All active calls on the same flag form a single total order consisting of zero or more exceptional calls, followed by one returning call. The end of each active call synchronizes-with the next active call in that order. >>> The return from the returning call synchronizes-with the returns from all passive calls on the same flag: this means that all concurrent calls to std::call_once are guaranteed to observe any side-effects made by the active call, with no additional synchronization. > > I don't think we should promise this even though it might be the case. What is the benefit of not promising it? Promising helps the supplier to have a well-defined order of execution. Furthermore, even if you do not promise it, it is the only possible implementation now and people will depend on it regardless. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2027128199 From mcimadamore at openjdk.org Thu Apr 3 14:43:09 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 3 Apr 2025 14:43:09 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v36] In-Reply-To: <-H3A19LuNrURjLlvH7RqzUtn8qHz1ywC9xSDpMT2qmQ=.4646b6dd-1a7c-48fc-917c-eff7ef32571f@github.com> References: <3opJVhWPrXB0R9O-EL6Zd_VOTQT7GuzTIR_hKrfhIms=.fbb9b437-a6b4-4e5d-99ee-88fe8b83ca7f@github.com> <-H3A19LuNrURjLlvH7RqzUtn8qHz1ywC9xSDpMT2qmQ=.4646b6dd-1a7c-48fc-917c-eff7ef32571f@github.com> Message-ID: On Thu, 3 Apr 2025 12:17:03 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Move Serializable specs to @implNote > > src/java.base/share/classes/java/lang/StableValue.java line 653: > >> 651: * {@code null} element. >> 652: */ >> 653: static Function function(Set inputs, > > The javadoc should say that the returned function throws IAE if the input is not supported, right? An alternative would be to have a factory that returns `Function>` -- although that would be more cumbersome to use. And, same for `int function` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2027158601 From mcimadamore at openjdk.org Thu Apr 3 14:50:15 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 3 Apr 2025 14:50:15 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v40] In-Reply-To: <37CdPM7bEE8_OFcNuJfrGNmBAJPrw0yHNwGfry10wQI=.9c1394e3-6399-4e2d-8199-da5092bb6deb@github.com> References: <37CdPM7bEE8_OFcNuJfrGNmBAJPrw0yHNwGfry10wQI=.9c1394e3-6399-4e2d-8199-da5092bb6deb@github.com> Message-ID: On Thu, 3 Apr 2025 14:00:00 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Make the sqrt example different src/java.base/share/classes/java/lang/StableValue.java line 211: > 209: * StableValue.function(CACHED_KEYS, LOG2_ORIGINAL); > 210: * > 211: * public static double log2(int a) { IMHO this example reveals a lack of compositionality of the partial functions we have. If the functions returned optional (to indicate "not defined"), then code like this would become much simpler to express: return LOG2_CACHED.apply(a) .orElse(LOG2_ORIGINAL.apply(a)); It's not just that this is more fluent -- this is also using the caching function to check whether the input is cached or not -- instead of having a separate check (potentially duplicating the costs). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2027173623 From mcimadamore at openjdk.org Thu Apr 3 14:58:19 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 3 Apr 2025 14:58:19 GMT Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v40] In-Reply-To: <37CdPM7bEE8_OFcNuJfrGNmBAJPrw0yHNwGfry10wQI=.9c1394e3-6399-4e2d-8199-da5092bb6deb@github.com> References: <37CdPM7bEE8_OFcNuJfrGNmBAJPrw0yHNwGfry10wQI=.9c1394e3-6399-4e2d-8199-da5092bb6deb@github.com> Message-ID: On Thu, 3 Apr 2025 14:00:00 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Make the sqrt example different src/java.base/share/classes/java/lang/StableValue.java line 410: > 408: * semantics associated with {@code final} fields is too restrictive. > 409: *

> 410: * In JDK 24, {@code final} instance fields in records and hidden classes (such as classes I suggest to drop this -- we normally don't reference to JDK versions in the javadoc. Perhaps this para should say: The _content_ of a set stable value is treated as a constant by the JVM, provided that the reference to the stable value is also constant (e.g. in cases where the stable value itself is stored in a `static final` field). This means that, at least in some cases, access to the content of a stable value enjoys the same constant-folding optimizations that are available when accessing `static final` fields. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2027192344 From duke at openjdk.org Thu Apr 3 16:21:54 2025 From: duke at openjdk.org (Oleksii Sylichenko) Date: Thu, 3 Apr 2025 16:21:54 GMT Subject: RFR: 8353489: Increase timeout and improve Windows compatibility in test/jdk/java/lang/ProcessBuilder/Basic.java In-Reply-To: References: Message-ID: <28TMKelH5wo-fNPK9FkwUQUjDhVDJDD2Qr7YcYPu5x4=.30aae7c9-b4c9-4b7a-b9f0-8a3466c32f7b@github.com> On Thu, 6 Mar 2025 13:34:07 GMT, Oleksii Sylichenko wrote: > This PR proposes three improvements to the `Basic.java` test: > > 1. Increase Timeout > - The current timeout is insufficient when running the test in IntelliJ IDEA. > - I propose increasing it by one minute. > - The timeout value was last modified on May 13, 2010 (commit [56131863a71c](https://github.com/openjdk/jdk/commit/56131863a71ca552d0a881364bd2b3581e13f058)) and has remained unchanged since then. > > 2. Fix Incompatibility with Windows (Cygwin vs. Native) > - One of the tests executes the `echo` command. > - This works in Cygwin but fails when running the test in a pure Windows environment (e.g., IntelliJ IDEA). > - I propose replacing echo with `cmd /c echo.`, which produces the same output (a single newline) in Windows, ensuring compatibility. > > 3. Prevent Autorun Scripts in the `cmd /c set` Command > - The test runs `cmd /c set`, but in Windows, this may trigger autorun scripts. > - I propose adding the `/d` options to prevent autorun scripts from affecting the test results. > > These changes improve test reliability and ensure compatibility across different environments. > Testing: > - Verified that the test runs successfully in IntelliJ IDEA without timeout issues. > - Confirmed that `cmd /c echo.` produces the expected output in Windows. > - Ensured that `cmd /d /c set` correctly lists environment variables without executing autorun scripts. > > # Detailed Description > > ## echo > The following test fails in a clean Windows environment (e.g., when run from IntelliJ IDEA without Cygwin): > > //---------------------------------------------------------------- > // Test Runtime.exec(...envp...) with envstrings without any `=' > //---------------------------------------------------------------- > > with following error: > > Cannot run program "echo": CreateProcess error=2, The system cannot find the file specified > > > ## cmd.exe /c set > The following test fails in a Windows environment under specific conditions: > > //---------------------------------------------------------------- > // Test Runtime.exec(...envp...) > // Check for sort order of environment variables on Windows. > //---------------------------------------------------------------- > > with following error: > >>'+=+ > BAZ=GORP > CONDA_BAT=C:\.......\\miniconda3\\condabin\\conda.bat > CONDA_EXE=C:\........\\miniconda3\\Scripts\\conda.exe > CONDA_SHLVL=0 > FOO=BAR > PATH=C:\.........\\miniconda3\\condabin; > QUUX= > SystemRoot=C:\\WINDOWS > _=_ > ~=~ > '< not equal to '+=+ > BAZ=GORP > FOO=BAR > QUUX= > SystemRoot=C:\\WINDOWS > _=_ > ~=~ > ' > > > **Reason** > In my ... keep-alive ------------- PR Comment: https://git.openjdk.org/jdk/pull/23933#issuecomment-2776320251 From naoto at openjdk.org Thu Apr 3 17:39:52 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 3 Apr 2025 17:39:52 GMT Subject: RFR: 8353585: Provide ChoiceFormat#parse(String, ParsePosition) tests In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 22:27:14 GMT, Justin Lu wrote: > Please review this PR which provides unit tests for `ChoiceFormat#parse(String, ParsePosition)` to check default, multi match, and no match behavior. There were no existing relevant tests. Looks good. test/jdk/java/text/Format/ChoiceFormat/ParseTest.java line 71: > 69: Arguments.of("1#a|2#aa", "aabb", 2d, 0), > 70: Arguments.of("1#a|2#aa", "bbaa", Double.NaN, 0), > 71: Arguments.of("1#aa|2#aaa", "a", Double.NaN, 0) Might be useful if we had negative or beyond input length position cases, which should produce `NaN` ------------- PR Review: https://git.openjdk.org/jdk/pull/24395#pullrequestreview-2740682293 PR Review Comment: https://git.openjdk.org/jdk/pull/24395#discussion_r2027470610 From jlahoda at openjdk.org Thu Apr 3 17:59:52 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 3 Apr 2025 17:59:52 GMT Subject: RFR: 8352693: Use a simpler console reader instead of JLine for System.console() [v2] In-Reply-To: References: Message-ID: > The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell. > > The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend. > > The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior. Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision: - Using control characters to get backspace control character. - If there's no native library available, fall back to the standard provider. - Reflecting review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24242/files - new: https://git.openjdk.org/jdk/pull/24242/files/77c41e46..d5176d68 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24242&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24242&range=00-01 Stats: 152 lines in 11 files changed: 114 ins; 13 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/24242.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24242/head:pull/24242 PR: https://git.openjdk.org/jdk/pull/24242 From jlahoda at openjdk.org Thu Apr 3 18:12:54 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 3 Apr 2025 18:12:54 GMT Subject: RFR: 8352693: Use a simpler console reader instead of JLine for System.console() [v3] In-Reply-To: References: Message-ID: > The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell. > > The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend. > > The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior. Jan Lahoda 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 branch 'master' into JDK-8352693 - Using control characters to get backspace control character. - If there's no native library available, fall back to the standard provider. - Reflecting review feedback. - Removing trailing whitespace - 8352693: Use a simpler console reader instead of JLine for System.console() ------------- Changes: https://git.openjdk.org/jdk/pull/24242/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24242&range=02 Stats: 2519 lines in 19 files changed: 1920 ins; 592 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/24242.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24242/head:pull/24242 PR: https://git.openjdk.org/jdk/pull/24242 From jlahoda at openjdk.org Thu Apr 3 18:12:54 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 3 Apr 2025 18:12:54 GMT Subject: RFR: 8352693: Use a simpler console reader instead of JLine for System.console() [v2] In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 17:59:52 GMT, Jan Lahoda wrote: >> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell. >> >> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend. >> >> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior. > > Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision: > > - Using control characters to get backspace control character. > - If there's no native library available, fall back to the standard provider. > - Reflecting review feedback. I have updated the PR based on most of the review comments so far: - removed the unnecessary qualified exports (https://github.com/openjdk/jdk/pull/24242/commits/91fa1b28e0436e55eed9cdee07e0e28c25bf666a) - reduced line lengths (https://github.com/openjdk/jdk/pull/24242/commits/91fa1b28e0436e55eed9cdee07e0e28c25bf666a) - cleaned comments in the C code (https://github.com/openjdk/jdk/pull/24242/commits/91fa1b28e0436e55eed9cdee07e0e28c25bf666a) - cleaned up the makefiles (https://github.com/openjdk/jdk/pull/24242/commits/91fa1b28e0436e55eed9cdee07e0e28c25bf666a) - if the native library (for UNIX) is not available, fall back to the simple/default provider (although support for AIX would be great, of course) (https://github.com/openjdk/jdk/pull/24242/commits/c6256eeeabfd73e7e67bf7f8c18c337e6bb92534) - I realized the backspace value can (and should) be read from the terminal as a control character, so I did that (https://github.com/openjdk/jdk/pull/24242/commits/d5176d68e8cc73914a0efef45a60f0ff03885bcc) ------------- PR Comment: https://git.openjdk.org/jdk/pull/24242#issuecomment-2776568012 From mdonovan at openjdk.org Thu Apr 3 18:53:35 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 3 Apr 2025 18:53:35 GMT Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms 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. ------------- Commit messages: - 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms Changes: https://git.openjdk.org/jdk/pull/24424/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24424&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351354 Stats: 23 lines in 1 file changed: 22 ins; 0 del; 1 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 smarks at openjdk.org Thu Apr 3 19:53:12 2025 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 3 Apr 2025 19:53:12 GMT Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method [v13] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 21:59:32 GMT, David Beaumont wrote: >> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method. >> >> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package. >> 2. Add explanatory comments to various affected methods. >> 3. Add a test to ensure deadlocks no longer occur. >> >> Note that this change does not address issue in MemoryHandler (see JDK-8349208). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Tweak wording. Looks good, thanks for the updates. ------------- Marked as reviewed by smarks (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23491#pullrequestreview-2740978356 From duke at openjdk.org Thu Apr 3 19:53:12 2025 From: duke at openjdk.org (duke) Date: Thu, 3 Apr 2025 19:53:12 GMT Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method [v13] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 21:59:32 GMT, David Beaumont wrote: >> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method. >> >> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package. >> 2. Add explanatory comments to various affected methods. >> 3. Add a test to ensure deadlocks no longer occur. >> >> Note that this change does not address issue in MemoryHandler (see JDK-8349208). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Tweak wording. @david-beaumont Your change (at version 8db4c907633fed5aa103b3c4f6aaad5096f0790a) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23491#issuecomment-2776774585 From asemenyuk at openjdk.org Thu Apr 3 20:02:28 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 3 Apr 2025 20:02:28 GMT Subject: RFR: 8353679: Restructure classes in jdk.jpackage.internal package Message-ID: - Move ConfigException, PackagerException, MsiVersion, and DottedVersion classes from "jdk.jpackage.internal" package to "jdk.jpackage.internal.model" package. - Remove public ctor from DottedVersion class. It can only be constructed with `DottedVersion.lazy()` and `DottedVersion.greedy()` functions. - Move PathGroup class from "jdk.jpackage.internal" package to "jdk.jpackage.internal.util" package. - Move internal "MacHelper.PListWrapper" class into "jdk.jpackage.internal.util.PListReader". Add unit tests. - Move internal "jdk.jpackage.internal.I18N.MultiResourceBundle" class into "jdk.jpackage.internal.util.MultiResourceBundle" - Remove dead code from "src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties" - Make PlatformVersionTest fail if reflection fails to locate expected version class. ------------- Commit messages: - Merge branch 'master' into rearrange-classes - Remove unused localized strings - Move MacHelper.PListWrapper to utils.PListReader - - move I18N.MultiResourceBundle to util.MultiResourceBundle; Changes: https://git.openjdk.org/jdk/pull/24358/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24358&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353679 Stats: 1314 lines in 49 files changed: 860 ins; 367 del; 87 mod Patch: https://git.openjdk.org/jdk/pull/24358.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24358/head:pull/24358 PR: https://git.openjdk.org/jdk/pull/24358 From asemenyuk at openjdk.org Thu Apr 3 20:02:28 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 3 Apr 2025 20:02:28 GMT Subject: RFR: 8353679: Restructure classes in jdk.jpackage.internal package In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 15:18:13 GMT, Alexey Semenyuk wrote: > - Move ConfigException, PackagerException, MsiVersion, and DottedVersion classes from "jdk.jpackage.internal" package to "jdk.jpackage.internal.model" package. > - Remove public ctor from DottedVersion class. It can only be constructed with `DottedVersion.lazy()` and `DottedVersion.greedy()` functions. > - Move PathGroup class from "jdk.jpackage.internal" package to "jdk.jpackage.internal.util" package. > - Move internal "MacHelper.PListWrapper" class into "jdk.jpackage.internal.util.PListReader". Add unit tests. > - Move internal "jdk.jpackage.internal.I18N.MultiResourceBundle" class into "jdk.jpackage.internal.util.MultiResourceBundle" > - Remove dead code from "src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties" > - Make PlatformVersionTest fail if reflection fails to locate expected version class. @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/24358#issuecomment-2776790633 From duke at openjdk.org Thu Apr 3 20:14:01 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 3 Apr 2025 20:14:01 GMT Subject: Integrated: 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 12:07:57 GMT, David Beaumont wrote: > 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method. > > 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package. > 2. Add explanatory comments to various affected methods. > 3. Add a test to ensure deadlocks no longer occur. > > Note that this change does not address issue in MemoryHandler (see JDK-8349208). This pull request has now been integrated. Changeset: ebcb9a8b Author: David Beaumont Committer: Stuart Marks URL: https://git.openjdk.org/jdk/commit/ebcb9a8b128cc6411610566c8368db63d25a5127 Stats: 453 lines in 8 files changed: 430 ins; 8 del; 15 mod 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method Reviewed-by: dfuchs, smarks ------------- PR: https://git.openjdk.org/jdk/pull/23491 From smarks at openjdk.org Thu Apr 3 21:10:18 2025 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 3 Apr 2025 21:10:18 GMT Subject: RFR: 8353684: [BACKOUT] j.u.l.Handler classes create deadlock risk via synchronized publish() method Message-ID: Back out commit for [JDK-8349206](https://bugs.openjdk.org/browse/JDK-8349206) because of build failure. This reverts commit ebcb9a8b128cc6411610566c8368db63d25a5127. ------------- Commit messages: - 8353684: BACKOUT 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method Changes: https://git.openjdk.org/jdk/pull/24426/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24426&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353684 Stats: 453 lines in 8 files changed: 8 ins; 430 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/24426.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24426/head:pull/24426 PR: https://git.openjdk.org/jdk/pull/24426 From dholmes at openjdk.org Thu Apr 3 21:14:48 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 3 Apr 2025 21:14:48 GMT Subject: RFR: 8353684: [BACKOUT] j.u.l.Handler classes create deadlock risk via synchronized publish() method In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 21:03:08 GMT, Stuart Marks wrote: > Back out commit for [JDK-8349206](https://bugs.openjdk.org/browse/JDK-8349206) because of build failure. > > This reverts commit ebcb9a8b128cc6411610566c8368db63d25a5127. LGTM Thanks Stuart! ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24426#pullrequestreview-2741184864 From smarks at openjdk.org Thu Apr 3 21:17:57 2025 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 3 Apr 2025 21:17:57 GMT Subject: Integrated: 8353684: [BACKOUT] j.u.l.Handler classes create deadlock risk via synchronized publish() method In-Reply-To: References: Message-ID: <_sPvkGMUMwLFBj4icrKbBGp_HbAjTUBSPo7g4Dg2RtE=.c3acd13a-cda4-44ae-9626-908f897b18f5@github.com> On Thu, 3 Apr 2025 21:03:08 GMT, Stuart Marks wrote: > Back out commit for [JDK-8349206](https://bugs.openjdk.org/browse/JDK-8349206) because of build failure. > > This reverts commit ebcb9a8b128cc6411610566c8368db63d25a5127. This pull request has now been integrated. Changeset: 57df89c4 Author: Stuart Marks URL: https://git.openjdk.org/jdk/commit/57df89c46449a19bb626fee2ea01c868e6dfb712 Stats: 453 lines in 8 files changed: 8 ins; 430 del; 15 mod 8353684: [BACKOUT] j.u.l.Handler classes create deadlock risk via synchronized publish() method Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/24426 From jlu at openjdk.org Thu Apr 3 21:23:08 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 3 Apr 2025 21:23:08 GMT Subject: RFR: 8353585: Provide ChoiceFormat#parse(String, ParsePosition) tests [v2] In-Reply-To: References: Message-ID: <-E75OTUgSbq54CMgK9DU8KTqorFvDlY2xOg6Fr9L8yk=.982f252e-b74b-47f3-a483-5feb484e7ff7@github.com> > Please review this PR which provides unit tests for `ChoiceFormat#parse(String, ParsePosition)` to check default, multi match, and no match behavior. There were no existing relevant tests. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Naoto's review - neg and exceeding length PP index cases ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24395/files - new: https://git.openjdk.org/jdk/pull/24395/files/b9d6349c..1fb6a7a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24395&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24395&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24395.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24395/head:pull/24395 PR: https://git.openjdk.org/jdk/pull/24395 From almatvee at openjdk.org Thu Apr 3 21:43:56 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 3 Apr 2025 21:43:56 GMT Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables available in *.cfg files [v8] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 21:20:54 GMT, Alexey Semenyuk wrote: >> jpackage app laucnher will expand environment variables in .cfg files. >> >> Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and `$ROOTDIR` tokens with the corresponding path values. With this patch, any environment variable can be expanded. The syntax is shell-like `$ENV_VAR_NAME` or `${ENV_VAR_NAME}`. If `$ENV_VAR_NAME` syntax is used, the variable name stops at the first character outside of `[a-zA-Z0-9_]` character range. If `${ENV_VAR_NAME}` syntax is used, the variable name stops at the first `}` character after `${` substring. E.g: >> | String | Variables | Variable Values | Expanded String | Note | >> | -------- | ------- |------- |------- |------- | >> | 

Welcome $USER!
| 
USER
| 
USER=John
| 
Welcome John!
|| >> | 
Welcome $USER!
| 
USER
| 
not set
| 
Welcome $USER!
| Unset variables are not expanded. | >> | 
Welcome $USER2
| 
USER2
| 
USER2=John
| 
Welcome John!
|| >> | 
Welcome ${USER}2!
| 
USER
| 
USER=John
| 
Welcome John2!
|| >> | 
Welcome $USER-2!
| 
USER
| 
USER=John
| 
Welcome John-2!
|| >> | 
Welcome ${USER-2}!
| 
USER-2
| 
USER-2=John
| 
Welcome John!
| `USER-2` is likely to be an invalid env variable name, but jpackage launcher is not validating names. | >> >> `$` character combination prevents variable expansion: >> | String | Variables | Variable Values | Expanded String | >> | -------- | ------- |------- |------- | >> | 
Hello \$A! Bye $B
| B | 
B=John
| 
Hello $A! Bye John
| >> | 
Hello \${A}! Bye $B
| B | 
B=John
| 
Hello ${A}! Bye John
| >> >> `\` character combination escapes ``: >> | String | Variables | Variable Values | Expanded String | >> | -------- | ------- |------- |------- | >> | 
Hello \\\$A! Bye $B
| A, B | 
A=Ana
B=John
| 
Hello \\Ana! Bye John
| >> >> If `` character is not followed by another `` character or `$` character, it is interpreted as a regular character: >> | String | Expanded string | >> | -------- | ------- | >> |
a\\b\\c
|
a\\b\\c
| >> >> >> Expansion is non-recursive: >> | String | Variables | Variable Values | Expanded String | Note | >> | -------- | ------- |------- |------- |------- | >> | 
Hello $A!
| A | 
A...
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor

Latest changes looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23923#pullrequestreview-2741233264

From asemenyuk at openjdk.org  Thu Apr  3 22:20:50 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 3 Apr 2025 22:20:50 GMT
Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables
 available in *.cfg files [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 1 Apr 2025 21:20:54 GMT, Alexey Semenyuk  wrote:

>> jpackage app laucnher will expand environment variables in .cfg files.
>> 
>> Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and `$ROOTDIR` tokens with the corresponding path values. With this patch, any environment variable can be expanded. The syntax is shell-like `$ENV_VAR_NAME` or `${ENV_VAR_NAME}`. If `$ENV_VAR_NAME` syntax is used, the variable name stops at the first character outside of `[a-zA-Z0-9_]` character range. If `${ENV_VAR_NAME}` syntax is used, the variable name stops at the first `}` character after `${` substring. E.g:
>> | String    | Variables | Variable Values | Expanded String | Note |
>> | -------- | ------- |------- |------- |------- |
>> | 
Welcome $USER!
  | 
USER
 | 
USER=John
 | 
Welcome John!
 ||
>> | 
Welcome $USER!
  | 
USER
 | 
not set
 | 
Welcome $USER!
 | Unset variables are not expanded. |
>> | 
Welcome $USER2
 | 
USER2
   | 
USER2=John
 | 
Welcome John!
 ||
>> | 
Welcome ${USER}2!
 | 
USER
  | 
USER=John
 | 
Welcome John2!
 ||
>> | 
Welcome $USER-2!
 | 
USER
   | 
USER=John
 | 
Welcome John-2!
 ||
>> | 
Welcome ${USER-2}!
 | 
USER-2
   | 
USER-2=John
 | 
Welcome John!
 | `USER-2` is likely to be an invalid env variable name, but jpackage launcher is not validating names. |
>> 
>> `$` character combination prevents variable expansion:
>> | String    | Variables | Variable Values | Expanded String |
>> | -------- | ------- |------- |------- |
>> | 
Hello \$A! Bye $B
  | B | 
B=John
 | 
Hello $A! Bye John
 |
>> | 
Hello \${A}! Bye $B
  | B | 
B=John
 | 
Hello ${A}! Bye John
 |
>> 
>> `\` character combination escapes ``:
>> | String    | Variables | Variable Values | Expanded String |
>> | -------- | ------- |------- |------- |
>> | 
Hello \\\$A! Bye $B
  | A, B | 
A=Ana
B=John
 | 
Hello \\Ana! Bye John
 |
>> 
>> If `` character is not followed by another `` character or `$` character, it is interpreted as a regular character:
>> | String    | Expanded string |
>> | -------- | ------- |
>> |
a\\b\\c
|
a\\b\\c
|
>> 
>> 
>> Expansion is non-recursive:
>> | String    | Variables | Variable Values | Expanded String | Note |
>> | -------- | ------- |------- |------- |------- |
>> | 
Hello $A!
  | A | 
A...
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor

I'll update the tests to cover case sensitivity differences on Unix and Windows.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23923#issuecomment-2777116973

From lmesnik at openjdk.org  Thu Apr  3 22:32:49 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 3 Apr 2025 22:32:49 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 2 Apr 2025 18:33:16 GMT, Kim Barrett  wrote:

>> Please review this change which adds a native method providing the
>> implementation of Reference::get.  Referece::get is an intrinsic candidate, so
>> this native method implementation is only used when the intrinsic is not.
>> 
>> Currently there is intrinsic support by the interpreter, C1, C2, and graal,
>> which are always used.  With this change we can later remove all the
>> per-platform interpreter intrinsic implementations, and might also remove the
>> C1 intrinsic implementation.
>> 
>> Testing:
>> (1) mach5 tier1-6 normal (so using all the existing intrinsics).
>> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled.
>
> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - remove timeout by using waitForReferenceProcessing
>  - make ill-timed gc in non-concurrent case less likely
>  - fix test package use

Test changes looks, good. Please get another review before pushing.

-------------

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24315#pullrequestreview-2741345881

From henryjen at openjdk.org  Fri Apr  4 00:44:18 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 4 Apr 2025 00:44:18 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate
Message-ID: 

This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.

-------------

Commit messages:
 - 8345431: Detect duplicate entries in jar files with jar --validate

Changes: https://git.openjdk.org/jdk/pull/24430/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345431
  Stats: 118 lines in 4 files changed: 98 ins; 2 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/24430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24430/head:pull/24430

PR: https://git.openjdk.org/jdk/pull/24430

From liach at openjdk.org  Fri Apr  4 01:01:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 4 Apr 2025 01:01:59 GMT
Subject: RFR: 8350704: Create tests to ensure the failure behavior of core
 reflection APIs [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 24 Mar 2025 21:29:29 GMT, Chen Liang  wrote:

>> Core reflection's generic signature parsing system is used for many aspects, including annotations and enclosing methods, yet it is under-tested. It is better for us to set up tests to ensure that sensitive error behaviors of core reflection remain the same across implementation updates, such as #19281.
>> 
>> This patch also includes a JUnit converted version of https://github.com/openjdk/jdk/pull/22581#issuecomment-2521703511 test checking behavior around annotations with duplicate interfaces. Interesting that this causes failure in class, field, and methods (constructors), but not in parameters.
>> 
>> Testing: jdk-tier 1, jdk-tier 2
>
> 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:
> 
>  - Forgot to commit the updated tests
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/reflect-behavior-tests
>  - Remove useless directive
>  - 8350704: Create tests to ensure the failure behavior of core reflection APIs

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23788#issuecomment-2777306417

From liach at openjdk.org  Fri Apr  4 01:02:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 4 Apr 2025 01:02:02 GMT
Subject: Integrated: 8350704: Create tests to ensure the failure behavior of
 core reflection APIs
In-Reply-To: 
References: 
Message-ID: 

On Tue, 25 Feb 2025 23:50:01 GMT, Chen Liang  wrote:

> Core reflection's generic signature parsing system is used for many aspects, including annotations and enclosing methods, yet it is under-tested. It is better for us to set up tests to ensure that sensitive error behaviors of core reflection remain the same across implementation updates, such as #19281.
> 
> This patch also includes a JUnit converted version of https://github.com/openjdk/jdk/pull/22581#issuecomment-2521703511 test checking behavior around annotations with duplicate interfaces. Interesting that this causes failure in class, field, and methods (constructors), but not in parameters.
> 
> Testing: jdk-tier 1, jdk-tier 2

This pull request has now been integrated.

Changeset: a449aeef
Author:    Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/a449aeef287d32437d23bb69027175d6d861e2a6
Stats:     788 lines in 7 files changed: 731 ins; 56 del; 1 mod

8350704: Create tests to ensure the failure behavior of core reflection APIs

Reviewed-by: darcy

-------------

PR: https://git.openjdk.org/jdk/pull/23788

From liach at openjdk.org  Fri Apr  4 01:02:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 4 Apr 2025 01:02:10 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Oct 2024 15:49:33 GMT, Chen Liang  wrote:

>> Please review this patch that:
>> 1. Implemented `forEach` to optimize for 1 or 2 element collections.
>> 2. Implemented `spliterator` to optimize for a single element.
>> 
>> The default implementations for multiple-element immutable collections are fine as-is, specializing implementation doesn't provide much benefit.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - s'marks requests
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Add test to ensure reproducible iteration order
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Use the improved form in forEach
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Null checks should probably be in the beginning...
>  - mark implicit null checks
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/7276a1be...4f1f4f1b

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15834#issuecomment-2777306371

From liach at openjdk.org  Fri Apr  4 01:02:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 4 Apr 2025 01:02:11 GMT
Subject: Integrated: 8327858: Improve spliterator and forEach for
 single-element immutable collections
In-Reply-To: 
References: 
Message-ID: 

On Wed, 20 Sep 2023 04:52:31 GMT, Chen Liang  wrote:

> Please review this patch that:
> 1. Implemented `forEach` to optimize for 1 or 2 element collections.
> 2. Implemented `spliterator` to optimize for a single element.
> 
> The default implementations for multiple-element immutable collections are fine as-is, specializing implementation doesn't provide much benefit.

This pull request has now been integrated.

Changeset: 1c2a5533
Author:    Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/1c2a5533f4e8926db18365eb510588594f8fb6ba
Stats:     126 lines in 3 files changed: 124 ins; 0 del; 2 mod

8327858: Improve spliterator and forEach for single-element immutable collections

Reviewed-by: smarks, vklang

-------------

PR: https://git.openjdk.org/jdk/pull/15834

From asemenyuk at openjdk.org  Fri Apr  4 01:14:37 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 4 Apr 2025 01:14:37 GMT
Subject: RFR: 8353681: jpackage suppresses errors when executed with --verbose
 option
Message-ID: 

Always print error messages from the last trapped exception to stderr. Optionally, print its stasktrace to stdout when in verbose mode.

Add relevant test.

-------------

Commit messages:
 - Print all errors when jpackage is executed with verbose output. Prior the fix it suppressed printing last error messages to stderr.
 - Add test.

Changes: https://git.openjdk.org/jdk/pull/24428/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24428&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353681
  Stats: 70 lines in 3 files changed: 40 ins; 11 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/24428.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24428/head:pull/24428

PR: https://git.openjdk.org/jdk/pull/24428

From asemenyuk at openjdk.org  Fri Apr  4 01:14:37 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 4 Apr 2025 01:14:37 GMT
Subject: RFR: 8353681: jpackage suppresses errors when executed with
 --verbose option
In-Reply-To: 
References: 
Message-ID: 

On Thu, 3 Apr 2025 21:36:10 GMT, Alexey Semenyuk  wrote:

> Always print error messages from the last trapped exception to stderr. Optionally, print its stasktrace to stdout when in verbose mode.
> 
> Add relevant test.

@sashamatveev PTAL

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24428#issuecomment-2776974265
PR Comment: https://git.openjdk.org/jdk/pull/24428#issuecomment-2777319162

From jpai at openjdk.org  Fri Apr  4 01:33:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 4 Apr 2025 01:33:48 GMT
Subject: RFR: 8352935: Launcher should not add $JDK/../lib to
 LD_LIBRARY_PATH [v2]
In-Reply-To: <-jGUmaeX6LpbFkDH7euctBwxj4t-qEeMB0VPKPAdJmo=.b21af75f-f50b-4d20-9e3f-a2e29b83c07a@github.com>
References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
 <-jGUmaeX6LpbFkDH7euctBwxj4t-qEeMB0VPKPAdJmo=.b21af75f-f50b-4d20-9e3f-a2e29b83c07a@github.com>
Message-ID: 

On Thu, 3 Apr 2025 12:57:40 GMT, Jaikiran Pai  wrote:

> Please give me a day or so to run this change against our CI.

tier1, tier2 and tier3 testing of this change went fine in our CI.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24351#issuecomment-2777338708

From almatvee at openjdk.org  Fri Apr  4 03:14:52 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 4 Apr 2025 03:14:52 GMT
Subject: RFR: 8353679: Restructure classes in jdk.jpackage.internal package
In-Reply-To: 
References: 
Message-ID: 

On Tue, 1 Apr 2025 15:18:13 GMT, Alexey Semenyuk  wrote:

> - Move ConfigException, PackagerException, MsiVersion, and DottedVersion classes from "jdk.jpackage.internal" package to "jdk.jpackage.internal.model" package.
>  - Remove public ctor from DottedVersion class. It can only be constructed with `DottedVersion.lazy()` and `DottedVersion.greedy()` functions.
>  - Move PathGroup class from "jdk.jpackage.internal" package to "jdk.jpackage.internal.util" package.
>  - Move internal "MacHelper.PListWrapper" class into "jdk.jpackage.internal.util.PListReader". Add unit tests.
>  - Move internal "jdk.jpackage.internal.I18N.MultiResourceBundle" class into "jdk.jpackage.internal.util.MultiResourceBundle"
>  - Remove dead code from "src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties"
>  - Make PlatformVersionTest fail if reflection fails to locate expected version class.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24358#pullrequestreview-2741667340

From almatvee at openjdk.org  Fri Apr  4 03:17:52 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 4 Apr 2025 03:17:52 GMT
Subject: RFR: 8353681: jpackage suppresses errors when executed with
 --verbose option
In-Reply-To: 
References: 
Message-ID: 

On Thu, 3 Apr 2025 21:36:10 GMT, Alexey Semenyuk  wrote:

> Always print error messages from the last trapped exception to stderr. Optionally, print its stasktrace to stdout when in verbose mode.
> 
> Add relevant test.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24428#pullrequestreview-2741671263

From eirbjo at openjdk.org  Fri Apr  4 04:51:12 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 4 Apr 2025 04:51:12 GMT
Subject: RFR: 8353662: Add test for non-local file URL fallback to FTP
Message-ID: 

Please review this test-only PR which introduces testing of the unspecified but long-standing fallback to FTP for non-local files in the 'file' URL scheme. 

This in preparation for the upcoming proposal to disable the feature by default in JDK-8353440.

Since we cannot reliably bind an FTP server to port 21, the test instead uses an HTTP proxy, binding to an ephemeral port. This menas we don't test non-proxy code paths. We still test that the FTP fallback is used, which is the key point here. (We aim to test file URL connections, not FTP URL connection internals) 

An alternative here could be to just verify that the returned URLConnection is an instance of FtpURLConnection. However, I opted for an end-to-end test here, since the amount of extra code seems reasonable.

By temporarly moving this test to tier1, I was able to confirm this test runs green also on Windows GHA.

-------------

Commit messages:
 - Add a test verifying non-local file: URL fallback to FTP

Changes: https://git.openjdk.org/jdk/pull/24418/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24418&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353662
  Stats: 141 lines in 1 file changed: 141 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24418.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24418/head:pull/24418

PR: https://git.openjdk.org/jdk/pull/24418

From iklam at openjdk.org  Fri Apr  4 06:21:49 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 4 Apr 2025 06:21:49 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive
In-Reply-To: 
References: 
Message-ID: <4h_JVYUvsLEwiafAxd4sSY6DsjlCZIHq_bE03wK4nuw=.707f5fc0-6b63-428d-9c21-0cccc8508ff6@github.com>

On Tue, 25 Mar 2025 11:08:24 GMT, Timofei Pushkin  wrote:

> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app.
> 
> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible.
> 
> Implementation note: `URLClassLoader` does not allow selecting a specific URL to load a specific class ? I used reflection to override a private part of `URLClassLoader` responsible for URL selection while being able to use the rest of its implementation.

Hi Timofei, thanks for fixing this. 

(Sorry I didn't notice this PR until now ...)

I have a suggestion for further simplification.

src/java.base/share/classes/jdk/internal/misc/CDS.java line 420:

> 418:                 // class loader. Thus it is safe to delegate their loading to system class loader
> 419:                 // (our parent) - this is what the default implementation of loadClass() will do.
> 420:                 return (Class) DEFINE_CLASS.invoke(this, name, res);

Instead of subclassing from `URLClassLoader` and go through the trouble of calling its `defineClass()` method, maybe we should just subclass from `ClassLoader` and maintain a hashtable of java.util.jar.JarFiles.


HashMap map = ....;
JarFile jar = map.get(source) ... or open a new JarFile if not found
byte[] buffer = read jar file for the given class name;
call ClassLoader.defineClass(buffer, ...)

src/java.base/share/classes/jdk/internal/misc/CDS.java line 446:

> 444:         protected Class findClass(String name) throws ClassNotFoundException {
> 445:             // Unregistered classes should be found in load(...), registered classes should be
> 446:             // handeled by parent loaders

This does seem like a good simplification, as we no longer need to check the `currentClassName`, `currentSuperClass`, etc. 

We had a plan for supported multiple classes for the same name, but we never go around doing it (even though the classlist format supports that with the use of IDs).

I am not sure if the current tests includes a case where a class name `Foo` exists both in the classpath as well as in a custom loader. If not, I think we should add such a case (to ensure that UnregisteredClassLoader never delegates to the application class loader and finds the wrong `Foo`).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24223#pullrequestreview-2741852934
PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2028155863
PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2028141440

From duke at openjdk.org  Fri Apr  4 06:55:00 2025
From: duke at openjdk.org (duke)
Date: Fri, 4 Apr 2025 06:55:00 GMT
Subject: Withdrawn: 8348556: Inlining fails earlier for
 MemorySegment::reinterpret
In-Reply-To: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
References: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
Message-ID: 

On Wed, 5 Feb 2025 10:17:09 GMT, Per Minborg  wrote:

> This PR proposes to add some `@ForceInline` annotations in the `Module` class in order to assist inlining of FFM var/method handles.
> 
> There are also some changes in other classes (notably `j.l.Object`) which, if implemented, can take us four additional levels of inlining. However, there is a tradeoff with adding `@ForceInline` and just trying to get as deep as possible for a specific use case is probably not the best idea. 
> 
> So, we should discuss which of the proposed changes (if any), we'd like to integrate.
> 
> Tested and passed tier1-3

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/23460

From clanger at openjdk.org  Fri Apr  4 07:56:43 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 4 Apr 2025 07:56:43 GMT
Subject: RFR: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public [v2]
In-Reply-To: 
References: 
Message-ID: 

> Alternative approach to #24012
> 
> This keeps the current handling of *.pdb vs *.stripped.pdb which allows debugging at the cost of a little hack in jlink. Maybe the code in jlink can be improved, e.g. make it more conditional.
> 
> I'm running this through our testing still to see whether it'll resolve all of the test issues and does not introduce regressions.

Christoph Langer 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-8351842-alternative
 - Extract fix for building debug symbols bundle
 - JDK-8351842

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24057/files
  - new: https://git.openjdk.org/jdk/pull/24057/files/9845a213..da632788

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24057&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24057&range=00-01

  Stats: 91537 lines in 2517 files changed: 34915 ins; 46252 del; 10370 mod
  Patch: https://git.openjdk.org/jdk/pull/24057.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24057/head:pull/24057

PR: https://git.openjdk.org/jdk/pull/24057

From alanb at openjdk.org  Fri Apr  4 07:57:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 4 Apr 2025 07:57:53 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493
In-Reply-To: <_mC3xJvbf0K_Bb4ywZIMUzDFiUzs70vIZz48z43R5-k=.3c8e049b-a869-4cfa-9623-c30ffea6c549@github.com>
References: 
 <9QVEBGTFqMGaocyisN_zUY9mqQtC3mnJoazB0TH0yqU=.6035d751-84b5-4aa3-baf5-e2d02f692565@github.com>
 <_mC3xJvbf0K_Bb4ywZIMUzDFiUzs70vIZz48z43R5-k=.3c8e049b-a869-4cfa-9623-c30ffea6c549@github.com>
Message-ID: 

On Thu, 3 Apr 2025 10:25:28 GMT, Severin Gehwolf  wrote:

> I'm not entirely sure what you are suggesting. Is it keeping a list of "upgradeable" files in a properties file. Files listed in that properties file aren't checked for hash sums (i.e. even if it's not modified)? That is, the explicit opt-in is not needed? Fine by me, but it's a weaker check. If we don't need the explicit opt-in, the patch becomes simpler as well.

Yes, I think keep simple. We always want to allow tzdb.dat be upgraded by the TZ updater tool. I think treating cacerts the same way is okay. As you note, it has to be kept up to date too. I was thinking keytool import and wasn't sure if the Linux distros configure with `-with-cacerts-file` or did something else. Thanks for the clarification on this point.

Starting with a simple list of two files won't preclude us from re-visiting it again in the future.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2777859174

From tschatzl at openjdk.org  Fri Apr  4 08:10:34 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 4 Apr 2025 08:10:34 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
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 39 commits:

 - * missing file from merge
 - 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 submit/8342382-card-table-instead-of-dcq
 - * make young gen length revising independent of refinement thread
     * use a service task
     * both refinement control thread and young gen length revising use the same infrastructure to get the number of available bytes and determine the time to the next update
 - * fix IR code generation tests that change due to barrier cost changes
 - * factor out card table and refinement table merging into a single
     method
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq3
 - * obsolete G1UpdateBufferSize
   
   G1UpdateBufferSize has previously been used to size the refinement
   buffers and impose a minimum limit on the number of cards per thread
   that need to be pending before refinement starts.
   
   The former function is now obsolete with the removal of the dirty
   card queues, the latter functionality has been taken over by the new
   diagnostic option `G1PerThreadPendingCardThreshold`.
   
   I prefer to make this a diagnostic option is better than a product option
   because it is something that is only necessary for some test cases to
   produce some otherwise unwanted behavior (continuous refinement).
   
   CSR is pending.
 - ... and 29 more: https://git.openjdk.org/jdk/compare/41d4a0d7...1c5a669f

-------------

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=29
  Stats: 7089 lines in 110 files changed: 2610 ins; 3555 del; 924 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 sgehwolf at openjdk.org  Fri Apr  4 08:24:48 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 4 Apr 2025 08:24:48 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493
In-Reply-To: 
References: 
 <9QVEBGTFqMGaocyisN_zUY9mqQtC3mnJoazB0TH0yqU=.6035d751-84b5-4aa3-baf5-e2d02f692565@github.com>
 <_mC3xJvbf0K_Bb4ywZIMUzDFiUzs70vIZz48z43R5-k=.3c8e049b-a869-4cfa-9623-c30ffea6c549@github.com>
 
Message-ID: 

On Fri, 4 Apr 2025 07:55:20 GMT, Alan Bateman  wrote:

> > I'm not entirely sure what you are suggesting. Is it keeping a list of "upgradeable" files in a properties file. Files listed in that properties file aren't checked for hash sums (i.e. even if it's not modified)? That is, the explicit opt-in is not needed? Fine by me, but it's a weaker check. If we don't need the explicit opt-in, the patch becomes simpler as well.
> 
> Yes, I think keep simple. We always want to allow tzdb.dat be upgraded by the TZ updater tool. I think treating cacerts the same way is okay. As you note, it has to be kept up to date too. I was thinking keytool import and wasn't sure if the Linux distros configure with `-with-cacerts-file` or did something else. Thanks for the clarification on this point.
> 
> Starting with a simple list of two files won't preclude us from re-visiting it again in the future.

OK. Thanks. I'll update it then.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2777914239

From pminborg at openjdk.org  Fri Apr  4 08:54:09 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 4 Apr 2025 08:54:09 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v40]
In-Reply-To: 
References: 
 <37CdPM7bEE8_OFcNuJfrGNmBAJPrw0yHNwGfry10wQI=.9c1394e3-6399-4e2d-8199-da5092bb6deb@github.com>
 
Message-ID: <4miyxAjUYQS9tiuEfboyDWVle72_XykuohI97UeGdM0=.8ee8b165-379d-4860-bf75-0b968361f9b9@github.com>

On Thu, 3 Apr 2025 14:20:42 GMT, Archie Cobbs  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make the sqrt example different
>
> src/java.base/share/classes/java/lang/StableValue.java line 383:
> 
>> 381:  * (e.g. {@linkplain #trySet(Object) trySet()})
>> 382:  * {@linkplain java.util.concurrent##MemoryVisibility happens-before}
>> 383:  * any subsequent read operation (e.g. {@linkplain #orElseThrow()}) that is successful.
> 
> Is `isSet()` also considered to be a "read operation"? I would assume so, but that requires a bit of reading between the lines. Maybe `isSet()` could be added as another parenthetical example after `orElseThrow()` here to squash that particular ambiguity.

Very good observation. I will clarify this. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2028387857

From pminborg at openjdk.org  Fri Apr  4 08:58:05 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 4 Apr 2025 08:58:05 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v40]
In-Reply-To: 
References: 
 <37CdPM7bEE8_OFcNuJfrGNmBAJPrw0yHNwGfry10wQI=.9c1394e3-6399-4e2d-8199-da5092bb6deb@github.com>
 
Message-ID: 

On Thu, 3 Apr 2025 14:46:49 GMT, Maurizio Cimadamore  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make the sqrt example different
>
> src/java.base/share/classes/java/lang/StableValue.java line 211:
> 
>> 209:  *             StableValue.function(CACHED_KEYS, LOG2_ORIGINAL);
>> 210:  *
>> 211:  *     public static double log2(int a) {
> 
> IMHO this example reveals a lack of compositionality of the partial functions we have. If the functions returned optional (to indicate "not defined"), then code like this would become much simpler to express:
> 
> 
> return LOG2_CACHED.apply(a)
>            .orElse(LOG2_ORIGINAL.apply(a));
> 
> 
> It's not just that this is more fluent -- this is also using the caching function to check whether the input is cached or not -- instead of having a separate check (potentially duplicating the costs).

I agree with this observation. We should look at providing true partial functions using for example `Optional`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2028394873

From pminborg at openjdk.org  Fri Apr  4 09:14:22 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 4 Apr 2025 09:14:22 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v41]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Address comments on docs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/c80452c8..35ced190

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=40
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=39-40

  Stats: 13 lines in 1 file changed: 1 ins; 4 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From duke at openjdk.org  Fri Apr  4 09:21:10 2025
From: duke at openjdk.org (Markus KARG)
Date: Fri, 4 Apr 2025 09:21:10 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG  wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'

All requested changes are included in this PR since last week. Kindly asking to re-review / mark as reviewed, so we can proceed with the needed CSR. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2778044566

From jkern at openjdk.org  Fri Apr  4 09:22:10 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 4 Apr 2025 09:22:10 GMT
Subject: RFR: 8352935: Launcher should not add $JDK/../lib to
 LD_LIBRARY_PATH [v3]
In-Reply-To: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
Message-ID: 

> In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so.
> 
> The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  Proposal from RealCLanger to further cleanup test Test7029048

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24351/files
  - new: https://git.openjdk.org/jdk/pull/24351/files/6f32ead9..4dc7da09

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24351&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24351&range=01-02

  Stats: 23 lines in 1 file changed: 2 ins; 16 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24351.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24351/head:pull/24351

PR: https://git.openjdk.org/jdk/pull/24351

From clanger at openjdk.org  Fri Apr  4 09:27:53 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 4 Apr 2025 09:27:53 GMT
Subject: RFR: 8352935: Launcher should not add $JDK/../lib to
 LD_LIBRARY_PATH [v3]
In-Reply-To: 
References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
 
Message-ID: 

On Fri, 4 Apr 2025 09:22:10 GMT, Joachim Kern  wrote:

>> In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so.
>> 
>> The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Proposal from RealCLanger to further cleanup test Test7029048

Thanks for adding the additional test cleanups. Let's run it through our testing once more.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24351#issuecomment-2778062669

From mcimadamore at openjdk.org  Fri Apr  4 10:24:09 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 4 Apr 2025 10:24:09 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v40]
In-Reply-To: 
References: 
 <37CdPM7bEE8_OFcNuJfrGNmBAJPrw0yHNwGfry10wQI=.9c1394e3-6399-4e2d-8199-da5092bb6deb@github.com>
 
 
Message-ID: 

On Fri, 4 Apr 2025 08:55:19 GMT, Per Minborg  wrote:

>> src/java.base/share/classes/java/lang/StableValue.java line 211:
>> 
>>> 209:  *             StableValue.function(CACHED_KEYS, LOG2_ORIGINAL);
>>> 210:  *
>>> 211:  *     public static double log2(int a) {
>> 
>> IMHO this example reveals a lack of compositionality of the partial functions we have. If the functions returned optional (to indicate "not defined"), then code like this would become much simpler to express:
>> 
>> 
>> return LOG2_CACHED.apply(a)
>>            .orElse(LOG2_ORIGINAL.apply(a));
>> 
>> 
>> It's not just that this is more fluent -- this is also using the caching function to check whether the input is cached or not -- instead of having a separate check (potentially duplicating the costs).
>
> I agree with this observation. We should look at providing true partial functions using for example `Optional`.

Btw, I believe for now we should just "note" the issue, and move one. Let's have the javadoc reflect what the impl really does. We have good ideas on how to address this, so we can either follow up with a CSR post-integration, or we can address this in the next round of preview

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2028541047

From mcimadamore at openjdk.org  Fri Apr  4 10:24:11 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 4 Apr 2025 10:24:11 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v41]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 4 Apr 2025 09:14:22 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments on docs

src/java.base/share/classes/java/lang/StableValue.java line 407:

> 405:  * The _content_ of a set stable value is treated as a constant by the JVM, provided that
> 406:  * the reference to the stable value is also constant (e.g. in cases where the
> 407:  * stable value itself is stored in a `static final` field).

watch out for the markdown quotes :-)

src/java.base/share/classes/java/lang/StableValue.java line 411:

> 409:  * This means that, at least in some cases, access to the content of a stable value
> 410:  * enjoys the same constant-folding optimizations that are available when accessing
> 411:  * `static final` fields.

We probably need to extra para that says something about stable suppliers/functions etc. E.g. since these are cleanly built on top of SV, if these are constants (again, stored in `static final` field) their access can be constant-folded. E.g. make it clear that this property is compositional. It doesn't just hold for a single constant SV, but also for another constant objects that wraps a SV.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2028542265
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2028544663

From duke at openjdk.org  Fri Apr  4 10:29:45 2025
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Fri, 4 Apr 2025 10:29:45 GMT
Subject: RFR: 8352016: Improve
 java/lang/RuntimeTests/RuntimeExitLogTest.java [v2]
In-Reply-To: 
References: 
 <-caOgyxT1C2x7Zg6bLcOxmY5u7P0quCuYGvrJWiyH-s=.34fc6ea6-748e-4f78-aeff-29d43aaca285@github.com>
 
Message-ID: 

On Wed, 26 Mar 2025 16:24:20 GMT, Jaikiran Pai  wrote:

>> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8352016: Improve java/lang/RuntimeTests/RuntimeExitLogTest.java
>
> test/jdk/java/lang/RuntimeTests/RuntimeExitLogTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.
> 
> Hello @tkiriyama, this should be `2023, 2025, `.

I'm sorry. I fixed this mistake.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24050#discussion_r2028550287

From duke at openjdk.org  Fri Apr  4 10:29:43 2025
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Fri, 4 Apr 2025 10:29:43 GMT
Subject: RFR: 8352016: Improve
 java/lang/RuntimeTests/RuntimeExitLogTest.java [v3]
In-Reply-To: 
References: 
Message-ID: 

> The current test program for the logging feature added in JDK-8301627 does not fully check some important cases.
> 
> Issue Details:
> The test does not properly check cases where logging might not happen due to different logging levels. (e.g. ALL, TRACE, WARNING, etc.)
> The check for the logged stack trace is not enough, as it does not confirm enough details in the output.
> 
> Fix Details:
> Added more test cases to check behavior under different logging levels.
> Improved the stack trace check by verifying more details in the logged output.
> These changes make the test more complete and ensure that the logging feature works as expected.
> Also, any existing test cases prior to this pull request are retained.
> 
> The test was verified in the following OS environments, and it passed successfully in both environments.
> - Windows Server 2022 Standard 21H2
> - Red Hat Enterprise Linux release 9.2 (Plow)
> 
> Could you please review this fix?

KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:

  8352016: Improve java/lang/RuntimeTests/RuntimeExitLogTest.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24050/files
  - new: https://git.openjdk.org/jdk/pull/24050/files/68024f93..889dd7f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24050&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24050&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24050.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24050/head:pull/24050

PR: https://git.openjdk.org/jdk/pull/24050

From maurizio.cimadamore at oracle.com  Fri Apr  4 10:32:34 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 4 Apr 2025 11:32:34 +0100
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
 <1257824626.204034517.1743604437041.JavaMail.zimbra@univ-eiffel.fr>
 
Message-ID: 

In general I don't disagree.


There is, however, at least _some_ cases where the imperative API is 
less difficult to use.


In some cases you know that a class has a complex lifecycle -- perhaps 
it starts off in a simple "larval" state, where the instance only exist 
in a single thread.


In this state, it's possible for the class to receive state updates. If 
parts of the class state are stable, using `trySet` might work very 
well. Perhaps only "friends" of this class can call such mutator methods 
on the larval instance.


At some point later in the class lifetime, it becomes "frozen", and it 
is published to multiple threads.


Of course, this is a corner case -- but if our goal is to model what 
`@Stable` can do, while surely a stable supplier, or using `orElseSet` 
are better no-worry alternatives to get there, there remain a number of 
use cases that would not be expressible if all we had was the high-level 
API. In a way, a big part of what this new API does is that it finds the 
right set of primitives, upon which we can build all the other 
interesting high-level stuff.


I think your complaint is not that the primitive is wrong, but that in 
calling the primitive StableValue we're giving the "good name" to the 
stuff that is less likely to be widely used.


(Note: a very minimalistic API approach -- which we considered -- would 
have been to just provide extra stable factories in 
Supplier/Function/IntFunction/List/Map and call it a day)


Maurizio


On 03/04/2025 12:20, Per-Ake Minborg wrote:
> Hi Remi and thank you for the feedback from JChateau?(what a wonderful 
> name!).
>
> This is one of the issues we already have on the list for the next 
> round of preview. Now we know more folks are on the same page.
>
> Best, Per
> ------------------------------------------------------------------------
> *From:* Remi Forax 
> *Sent:* Wednesday, April 2, 2025 4:33 PM
> *To:* Per Minborg 
> *Cc:* compiler-dev ; core-libs-dev 
> ; hotspot-dev ; 
> security-dev 
> *Subject:* Re: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
> Hi Per,
> last week, at JChateau, we had a one hour session about stable values, 
> I've build the JDK with this PR so we can discuss about it.
>
> To present the API, i start from the double check locking, rewriting 
> it to use the StableValue API.
>
> The main remark was that methods like orElseSet() or isSet() are hard 
> to used correctly.
>
> In my opinion, the current API is a mix of a high level API and a 
> low-level API but it's too easy to misuse the low-level API.
>
>
> high level:
> - methods supplier(), list() and map()
> ? Those are easy to use
>
> low level:
> - methods: of, of(value), orElseSet, setOrThrow(), etc
> ? Those are hard to use properly.
>
> I think, not necessary in this PR, that the current API should be 
> separated into two different classes, one in java.lang with the high 
> level API (the static methods other than Of() and one in 
> java.util.concurrent with the low level API where you have to know 
> what you are doing (like with any classes of java.util.concurrent).
>
> regards,
> R?mi
>
> ----- Original Message -----
> > From: "Per Minborg" 
> > To: "compiler-dev" , "core-libs-dev" 
> , "hotspot-dev"
> > , "security-dev" 
> > Sent: Thursday, March 13, 2025 12:20:10 PM
> > Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
>
> > Implement JEP 502.
> >
> > The PR passes tier1-tier3 tests.
> >
> > -------------
> >
> > Commit messages:
> > - Use acquire semantics for reading rather than volatile semantics
> > - Add missing null check
> > - Simplify handling of sentinel, wrap, and unwrap
> > - Fix JavaDoc issues
> > - Fix members in StableEnumFunction
> > - Address some comments in the PR
> > - Merge branch 'master' into implement-jep502
> > - Revert change
> > - Fix copyright issues
> > - Update JEP number
> > - ... and 231 more: 
> https://git.openjdk.org/jdk/compare/4cf63160...09ca44e6
> >
> > Changes: https://git.openjdk.org/jdk/pull/23972/files
> >? Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=00 
> 
> >? Issue: https://bugs.openjdk.org/browse/JDK-8351565
> >? Stats: 3980 lines in 30 files changed: 3949 ins; 18 del; 13 mod
> >? Patch: https://git.openjdk.org/jdk/pull/23972.diff
> >? Fetch: git fetch https://git.openjdk.org/jdk.git 
> pull/23972/head:pull/23972
> >
> > PR: https://git.openjdk.org/jdk/pull/23972
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Fri Apr  4 10:33:00 2025
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Fri, 4 Apr 2025 10:33:00 GMT
Subject: RFR: 8352016: Improve
 java/lang/RuntimeTests/RuntimeExitLogTest.java [v3]
In-Reply-To: <8rQ6xcA92Dj-9A_WjlAX1P9GVL2tLZkcgB8hiZSoc7g=.ae9bd32e-a576-4bb8-8071-5194885b3efe@github.com>
References: 
 
 
 <8rQ6xcA92Dj-9A_WjlAX1P9GVL2tLZkcgB8hiZSoc7g=.ae9bd32e-a576-4bb8-8071-5194885b3efe@github.com>
Message-ID: 

On Tue, 25 Mar 2025 18:39:22 GMT, Roger Riggs  wrote:

>> I see. This test only takes a very short time, but shouldn't the cases be added?
>
> Still no, starting a new Java runtime isn't that quick, and it brings no additional value.
> All tests are run 10's of thousands of times in every release, adding a few seconds here and there add up.

Thank you for the additional comment!
I understand that two test cases are sufficient as a general test for loggers.
However, the valid level of "System.exit and Runtime.exit debug logging" is determined by the following specific implementation:
https://github.com/openjdk/jdk/blob/41d4a0d7bdda2a96af1e7f549c05d99d68c040dc/src/java.base/share/classes/java/lang/Shutdown.java#L175
Does this code need to be tested exhaustively?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24050#discussion_r2028556413

From mcimadamore at openjdk.org  Fri Apr  4 11:02:21 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 4 Apr 2025 11:02:21 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33]
In-Reply-To: 
References: 
 
 <4nLcumfsB_JNPi8xU5DZnorZvhllSjUz-zfop_CXXx8=.7122f5cf-6f22-4cc1-ba3e-cb57ade07e53@github.com>
 
 
 
 
Message-ID: 

On Thu, 3 Apr 2025 12:07:03 GMT, Maurizio Cimadamore  wrote:

>> There is a problem here: If we say it is "immutable content" people might think that passing mutable data makes it immutable. If we say it is "shallowly immutable content" people might think they cannot pass immutable data.
>> 
>> I am not so sure that the term "effectively immutable" is widely understood. 
>> 
>> Another alternative is to rephrase entirely and say something like
>> 
>> "A stable value is a holder of content that can be lazily computed at most once"
>
>> "A stable value is a holder of content that can be lazily computed at most once"
> 
> I'd replace `computed` with `set` (as that's the term we use in the API).

`A stable value is a holder of content that can be set at most once`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2028597302

From mcimadamore at openjdk.org  Fri Apr  4 11:10:08 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 4 Apr 2025 11:10:08 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v40]
In-Reply-To: 
References: 
 <37CdPM7bEE8_OFcNuJfrGNmBAJPrw0yHNwGfry10wQI=.9c1394e3-6399-4e2d-8199-da5092bb6deb@github.com>
 
 
 
Message-ID: 

On Fri, 4 Apr 2025 10:18:27 GMT, Maurizio Cimadamore  wrote:

>> I agree with this observation. We should look at providing true partial functions using for example `Optional`.
>
> Btw, I believe for now we should just "note" the issue, and move one. Let's have the javadoc reflect what the impl really does. We have good ideas on how to address this, so we can either follow up with a CSR post-integration, or we can address this in the next round of preview

(That said, perhaps the javadoc would be better off in showing examples that did not rely on totalizing partial behavior. The examples in the JEP don't do that, and so doesn't fibonacci. We should find a couple more like those).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2028606174

From asemenyuk at openjdk.org  Fri Apr  4 11:50:09 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 4 Apr 2025 11:50:09 GMT
Subject: Integrated: 8353679: Restructure classes in jdk.jpackage.internal
 package
In-Reply-To: 
References: 
Message-ID: 

On Tue, 1 Apr 2025 15:18:13 GMT, Alexey Semenyuk  wrote:

> - Move ConfigException, PackagerException, MsiVersion, and DottedVersion classes from "jdk.jpackage.internal" package to "jdk.jpackage.internal.model" package.
>  - Remove public ctor from DottedVersion class. It can only be constructed with `DottedVersion.lazy()` and `DottedVersion.greedy()` functions.
>  - Move PathGroup class from "jdk.jpackage.internal" package to "jdk.jpackage.internal.util" package.
>  - Move internal "MacHelper.PListWrapper" class into "jdk.jpackage.internal.util.PListReader". Add unit tests.
>  - Move internal "jdk.jpackage.internal.I18N.MultiResourceBundle" class into "jdk.jpackage.internal.util.MultiResourceBundle"
>  - Remove dead code from "src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties"
>  - Make PlatformVersionTest fail if reflection fails to locate expected version class.

This pull request has now been integrated.

Changeset: 10d1fec3
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/10d1fec3ff92de5b897737763972b62fba40753e
Stats:     1314 lines in 49 files changed: 860 ins; 367 del; 87 mod

8353679: Restructure classes in jdk.jpackage.internal package

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/24358

From asemenyuk at openjdk.org  Fri Apr  4 11:53:12 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 4 Apr 2025 11:53:12 GMT
Subject: Integrated: 8353681: jpackage suppresses errors when executed with
 --verbose option
In-Reply-To: 
References: 
Message-ID: 

On Thu, 3 Apr 2025 21:36:10 GMT, Alexey Semenyuk  wrote:

> Always print error messages from the last trapped exception to stderr. Optionally, print its stasktrace to stdout when in verbose mode.
> 
> Add relevant test.

This pull request has now been integrated.

Changeset: cfcb3305
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/cfcb3305f078b61b37037ef6f652303d6c2c7098
Stats:     70 lines in 3 files changed: 40 ins; 11 del; 19 mod

8353681: jpackage suppresses errors when executed with --verbose option

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/24428

From tpushkin at openjdk.org  Fri Apr  4 12:38:32 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 4 Apr 2025 12:38:32 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v2]
In-Reply-To: 
References: 
Message-ID: 

> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app.
> 
> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible.
> 
> Implementation note: `URLClassLoader` does not allow selecting a specific URL to load a specific class ? I used reflection to override a private part of `URLClassLoader` responsible for URL selection while being able to use the rest of its implementation.

Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:

  Test classpath case

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24223/files
  - new: https://git.openjdk.org/jdk/pull/24223/files/3be4c5f9..784c1a83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=00-01

  Stats: 53 lines in 1 file changed: 53 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24223.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223

PR: https://git.openjdk.org/jdk/pull/24223

From rriggs at openjdk.org  Fri Apr  4 12:44:03 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Apr 2025 12:44:03 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for removal
Message-ID: 

Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission

@Deprecated(forRemoval = true, since="25")
Is added to each class and the existing @apiNote is converted to @deprected

-------------

Commit messages:
 - 8353641: Deprecate core library permission classes for removal

Changes: https://git.openjdk.org/jdk/pull/24444/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353641
  Stats: 47 lines in 15 files changed: 28 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/24444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444

PR: https://git.openjdk.org/jdk/pull/24444

From dfuchs at openjdk.org  Fri Apr  4 12:56:03 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 4 Apr 2025 12:56:03 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal
In-Reply-To: 
References: 
Message-ID: 

On Fri, 4 Apr 2025 12:37:32 GMT, Roger Riggs  wrote:

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

Looks reasonable to me. Changes to LoggingPermission look good. Out of curiosity I also  looked at all usages of RuntimePermission in the JDK - I believe you caught them all - including the unexpected use in XSLT.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24444#issuecomment-2778654645

From duke at openjdk.org  Fri Apr  4 13:09:12 2025
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 4 Apr 2025 13:09:12 GMT
Subject: RFR: 8352536: Add overloads to parse and build class files from/to
 MemorySegment [v5]
In-Reply-To: <3ys064eF-itK8rIOyndej09DgSxT7x1OJpYrg1cCVWk=.f2032850-7fa8-4750-b102-6f6759d81921@github.com>
References: 
 <7nM7DyuP3sRhI0J2Im2UmpBsgSk_GsxbbVUxM2p4LP4=.061e853c-5234-4a5a-ac39-69eb932acd62@github.com>
 <3ys064eF-itK8rIOyndej09DgSxT7x1OJpYrg1cCVWk=.f2032850-7fa8-4750-b102-6f6759d81921@github.com>
Message-ID: 

On Fri, 28 Mar 2025 15:53:15 GMT, Adam Sotona  wrote:

>> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a benchmark for class file emission
>
> https://github.com/openjdk/jdk/pull/24297/files

I've had a look at the comparison benchmark and I did a couple other tests to see whether some percentage of pass-through versus recreation would show anything interesting. My conclusion is that @asotona is right in that when processing each element of, or just creating from scratch, any decently-sized class, the copy overhead vanishes in proportion to the overhead of class creation itself. The relative allocation overhead remains significant in this case, which may result in additional GC cycles. @liach is also correct in that we could theoretically reduce this allocation by avoiding the resize/copy cycle of byte arrays.

I remain convinced that none of this invalidates the usefulness of this change, or invalidates the argument that the cost of this change is low, but we're all busy people and so I'm not going to continue pushing this against a strong headwind. Maybe we can revisit it at some later time if there is enough interest from third parties. For now I will just live with the extra copies.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24139#issuecomment-2778685789

From duke at openjdk.org  Fri Apr  4 13:09:12 2025
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 4 Apr 2025 13:09:12 GMT
Subject: Withdrawn: 8352536: Add overloads to parse and build class files
 from/to MemorySegment
In-Reply-To: 
References: 
Message-ID: 

On Thu, 20 Mar 2025 19:49:33 GMT, David M. Lloyd  wrote:

> Provide method overloads to the ClassFile interface of the java.lang.classfile API which allow parsing of classes found in memory segments, as well as allowing built class files to be output to them.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24139

From mullan at openjdk.org  Fri Apr  4 13:12:50 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 4 Apr 2025 13:12:50 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
Message-ID: 

Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.

The current API note in these classes was reused as the deprecation text. 

Release Note: https://bugs.openjdk.org/browse/JDK-8353680

-------------

Commit messages:
 - Remove trailing whitespace.
 - Initial revision.

Changes: https://git.openjdk.org/jdk/pull/24445/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24445&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348967
  Stats: 53 lines in 15 files changed: 34 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/24445.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24445/head:pull/24445

PR: https://git.openjdk.org/jdk/pull/24445

From lancea at openjdk.org  Fri Apr  4 13:14:08 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 4 Apr 2025 13:14:08 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate
In-Reply-To: 
References: 
Message-ID: 

On Fri, 4 Apr 2025 00:39:04 GMT, Henry Jen  wrote:

> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.

Thank you for starting the work on this Henry.

A few initial comments/improvements based on an initial pass of your PR:

- Validate that the Entry names match between the LOC and CEN including the entry order within the headers (ZipOutputStream and most tools will write the LOC/CEN headers in the same order)
- Warn of duplicate entries
- Check that any LOC entry exists in the CEN and any CEN entry exists in the LOC
-  Be more specific in the warnings reported such as:  Entry  XXX found in the LOC but not the CEN
-  main.help.opt.main.validate in jar.properties should be updated  to indicate additional validation
- jar.md should also be updated for the same reason
- I would use this as an opportunity to add some comments as to what the methods such as validate are now doing given the  functions verification has been expanded


It would also be good to validate that the MANIFEST returned ZipFile and ZipInputStream match (this could be follow on work)

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 66:

> 64:     private String mdName;
> 65:     private final ZipInputStream zis;
> 66:     private final Set entryNames = new HashSet<>();

Please rename this to represent the CEN entries.

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 80:

> 78:     }
> 79: 
> 80:     private void checkDuplicates(ZipEntry e) {

Please add a general comment of the purpose as this method is only used with traversing the ZipFile and walking the CEN

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 86:

> 84:     }
> 85: 
> 86:     private void checkZipInputStream() {

Please add a comment on the purpose of the method

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 92:

> 90:             ZipEntry e;
> 91:             while ((e = zis.getNextEntry()) != null) {
> 92:                 var entryName = e.getName();

please rename to locEntryName

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 99:

> 97:                 if (!entryNames.contains(entryName)) {
> 98:                     missingEntryNames.add(entryName);
> 99:                 }

It looks like you are checking to see if the LOC entry contains within the CEN but I don't see if you are checking if the CEN entry is contained in the LOC

Another facet of validation is to compare the ordering of entries between the LOC and CEN

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 147:

> 145:         in incompatible public interfaces
> 146: warn.validator.duplicate.entry=\
> 147:         Warning: More than one copy of {0} is detected

How do we know if the duplicate entry is in the CEN or LOC?

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 149:

> 147:         Warning: More than one copy of {0} is detected
> 148: warn.validator.inconsistent.content=\
> 149:         Warning: The list of entries does not match the content

This message could be more specific to the type of error found

test/jdk/tools/jar/MultipleManifestTest.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 8335912 8345431

I would suggesting moving the validation for multiple entries, LOC/CEN mismatches into a separate test

-------------

PR Review: https://git.openjdk.org/jdk/pull/24430#pullrequestreview-2742819751
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2028719761
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2028722966
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2028727832
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2028730393
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2028742286
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2028755446
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2028756250
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2028758898

From duke at openjdk.org  Fri Apr  4 13:53:57 2025
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 4 Apr 2025 13:53:57 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
In-Reply-To: 
References: 
Message-ID: 

On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan  wrote:

> Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.

I agree with most of these, however the permissions infrastructure *itself* is still used for user-level authorization (at least in WildFly/JBoss middleware, and I would assume other places as well). Part of this infrastructure does rely on `AllPermission` and its `PermissionCollection`. I don't see a reason to deprecate `AllPermission` before deprecating `Permission` itself.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2778791218

From mullan at openjdk.org  Fri Apr  4 14:15:48 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 4 Apr 2025 14:15:48 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
In-Reply-To: 
References: 
Message-ID: <9F3RrRIQCRygi1beKlVOjCKbHaF-rDFh63UG1leNDq8=.24f6dca0-e6f6-4fed-ac9a-1355bb73c8be@github.com>

On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan  wrote:

> Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
> 
> The current API note in these classes was reused as the deprecation text. 
> 
> Release Note: https://bugs.openjdk.org/browse/JDK-8353680

> > Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
> 
> I agree with most of these, however the permissions infrastructure _itself_ is still used for user-level authorization (at least in WildFly/JBoss middleware, and I would assume other places as well). Part of this infrastructure does rely on `AllPermission` and its `PermissionCollection`. I don't see a reason to deprecate `AllPermission` before deprecating `Permission` itself.

Can you elaborate or give an example/pointer to code on how it uses `AllPermission` w/o the corresponding SM APIs and infrastructure (policy files, `AccessController`, etc)?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2778846121

From ihse at openjdk.org  Fri Apr  4 14:27:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Apr 2025 14:27:53 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console() [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 3 Apr 2025 18:12:54 GMT, Jan Lahoda  wrote:

>> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell.
>> 
>> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend.
>> 
>> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior.
>
> Jan Lahoda 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 branch 'master' into JDK-8352693
>  - Using control characters to get backspace control character.
>  - If there's no native library available, fall back to the standard provider.
>  - Reflecting review feedback.
>  - Removing trailing whitespace
>  - 8352693: Use a simpler console reader instead of JLine for System.console()

make/modules/jdk.internal.le/Lib.gmk line 31:

> 29: 
> 30: ifeq ($(call isTargetOs, linux macosx windows), true)
> 31: 

Can you please insert the standardized header we use for native libraries? (These are extremely helpful to find/locate where certain libraries are built, since there is no existing proper IDE support for makefiles.)

Suggestion:

  ##############################################################################
  ## Build lible
  ##############################################################################

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2028914120

From hannesw at openjdk.org  Fri Apr  4 14:32:45 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 4 Apr 2025 14:32:45 GMT
Subject: RFR: 8254622: Hide superclasses from conditionally exported packages
Message-ID: 

Please review an enhancement to treat classes and interfaces that are not included and not unconditionally exported as hidden. This means they do not show up in the generated documentation even if they are implemented or extended by a documented type. 

This change makes the `@hidden` JavaDoc tag unnecessary in two internal base classes that previously used it, `jdk.internal.vm.vector.VectorSupport` and `jdk.internal.event.Event`. The generated documentation is unchanged.

The change also adds support for the `@hidden` JavaDoc tag in interfaces, which was previously missing, and adds coverage to `TestHiddenTag.java`.

-------------

Commit messages:
 - Remove whitespace
 - Update copyright headers
 - Add test, support hidden interfaces
 - Merge branch 'master' into JDK-8254622
 - Tweak comments
 - 8254622: Hide superclasses from conditionally exported packages

Changes: https://git.openjdk.org/jdk/pull/24446/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24446&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8254622
  Stats: 382 lines in 19 files changed: 326 ins; 15 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/24446.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24446/head:pull/24446

PR: https://git.openjdk.org/jdk/pull/24446

From duke at openjdk.org  Fri Apr  4 14:51:58 2025
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 4 Apr 2025 14:51:58 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
In-Reply-To: <9F3RrRIQCRygi1beKlVOjCKbHaF-rDFh63UG1leNDq8=.24f6dca0-e6f6-4fed-ac9a-1355bb73c8be@github.com>
References: 
 <9F3RrRIQCRygi1beKlVOjCKbHaF-rDFh63UG1leNDq8=.24f6dca0-e6f6-4fed-ac9a-1355bb73c8be@github.com>
Message-ID: 

On Fri, 4 Apr 2025 14:12:55 GMT, Sean Mullan  wrote:

> > > Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
> > 
> > 
> > I agree with most of these, however the permissions infrastructure _itself_ is still used for user-level authorization (at least in WildFly/JBoss middleware, and I would assume other places as well). Part of this infrastructure does rely on `AllPermission` and its `PermissionCollection`. I don't see a reason to deprecate `AllPermission` before deprecating `Permission` itself.
> 
> Can you elaborate or give an example/pointer to code on how it uses `AllPermission` w/o the corresponding SM APIs and infrastructure (policy files, `AccessController`, etc)?

The [`wildfly-elytron`](https://github.com/wildfly-security/wildfly-elytron) project uses `Permission` and `PermissionCollection` as a standalone basic API to represent user authorization permissions. Some examples include `LoginPermission` and `RunAsPrincipalPermission`, and a special `NoPermission` class which is useful in certain situations.

The user authorization mechanism does not use policy files, security manager APIs, `AccessController` or any other JAAS-adjacent API for this purpose.

Security contexts are managed completely separately from the JDK using thread local scoping (planned to move to `ScopedValue` someday if/when it becomes available). Permissions are checked against the user security context (`org.wildfly.security.auth.server.SecurityIdentity`) by authorization-sensitive operations in both server and user code.

The `AllPermission` class is used for "superuser" authorization situations, and cases where the deployer opts out of authorization checks for whatever reason (for example, testing). We use it for role-based access control of the application server itself when access control checks pass, as well for superuser authorization cases, and probably other cases I'm forgetting about (it's one of those things that we always assumed would stick around forever, so we used it without a second thought).

`AllPermission` is an integral concept of permission sets, and thus we would be obliged to create our own if the JDK one disappeared, causing compatibility problems due to the class moving to a new package from the point of view of consumers. Its destiny should be tied to that of `Permission` itself in my opinion, because it is pretty fundamental.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2778956492

From duke at openjdk.org  Fri Apr  4 15:02:23 2025
From: duke at openjdk.org (robert engels)
Date: Fri, 4 Apr 2025 15:02:23 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
In-Reply-To: 
References: 
Message-ID: 

On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan  wrote:

> Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
> 
> The current API note in these classes was reused as the deprecation text. 
> 
> Release Note: https://bugs.openjdk.org/browse/JDK-8353680

Sad day when the Java backwards compatibility promise is thrown out the window because a bunch of developers need work to do. Removing these classes does nothing towards the reduced api surface the goal of removing the SM had. I suspect these classes haven?t changed in 20 years.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2778984443

From daniel.fuchs at oracle.com  Fri Apr  4 15:04:19 2025
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 4 Apr 2025 16:04:19 +0100
Subject: RFR: 8348967: Deprecate security permission classes for removal
In-Reply-To: 
References: 
 <9F3RrRIQCRygi1beKlVOjCKbHaF-rDFh63UG1leNDq8=.24f6dca0-e6f6-4fed-ac9a-1355bb73c8be@github.com>
 
Message-ID: 

Hi David,

Are there other subclasses of Permission that this framework uses?
More specifically - would it be fine to deprecate NetPermission,
URLPermission and SocketPermission classes?

best regards,

-- daniel

On 04/04/2025 15:51, David M. Lloyd wrote:
>> Can you elaborate or give an example/pointer to code on how it uses `AllPermission` w/o the corresponding SM APIs and infrastructure (policy files, `AccessController`, etc)?
> 
> The [`wildfly-elytron`](https://github.com/wildfly-security/wildfly-elytron) project uses `Permission` and `PermissionCollection` as a standalone basic API to represent user authorization permissions. Some examples include `LoginPermission` and `RunAsPrincipalPermission`, and a special `NoPermission` class which is useful in certain situations.
> 
> The user authorization mechanism does not use policy files, security manager APIs, `AccessController` or any other JAAS-adjacent API for this purpose.
> 
> Security contexts are managed completely separately from the JDK using thread local scoping (planned to move to `ScopedValue` someday if/when it becomes available). Permissions are checked against the user security context (`org.wildfly.security.auth.server.SecurityIdentity`) by authorization-sensitive operations in both server and user code.
> 
> The `AllPermission` class is used for "superuser" authorization situations, and cases where the deployer opts out of authorization checks for whatever reason (for example, testing). We use it for role-based access control of the application server itself when access control checks pass, as well for superuser authorization cases, and probably other cases I'm forgetting about (it's one of those things that we always assumed would stick around forever, so we used it without a second thought).
> 
> `AllPermission` is an integral concept of permission sets, and thus we would be obliged to create our own if the JDK one disappeared, causing compatibility problems due to the class moving to a new package from the point of view of consumers. Its destiny should be tied to that of `Permission` itself in my opinion, because it is pretty fundamental.
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2778956492


From sgehwolf at openjdk.org  Fri Apr  4 15:22:10 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 4 Apr 2025 15:22:10 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v2]
In-Reply-To: 
References: 
Message-ID: 

> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
> 
> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
> 
> 1. The list of upgradeable files is hard-coded to `lib/tzdb.dat` and `lib/security/cacerts`. Only those two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
> 2. The upgrade needs to be opt-in. Similar to `--ignore-signing-information` for signed modular JARs. A user needs to add `--upgrade-files=/` for it to succeed.
> 
> `--upgrade-files` is a hidden `jlink` option since it only does anything for JEP 493 enabled builds. Users get a hint to apply the option if they so desire:
> 
> Example:
> 
> 
> $ ./bin/jlink --add-modules java.base --output java.base-jdk
> Error: [..]/lib/security/cacerts has been modified
> Hint: lib/security/cacerts is an upgradeable file. Add --upgrade-files=java.base/lib/security/cacerts to allow the upgrade.
> 
> 
> using the hint we get:
> 
> 
> $ ./bin/jlink --add-modules java.base --output java.base-jdk --upgrade-files=java.base/lib/security/cacerts
> $ ./java.base-jdk/bin/java --list-modules
> java.base at 25-internal
> $ sha512sum ./java.base-jdk/lib/security/cacerts 
> cf2b4c17161e79001c8e07def3de36c0d523f00a2a6b6e33893a2a3669d930957c11ac765dd29d5ff80e63ad100ef0258291891377f7133b997111ba97b15146  ./java.base-jdk/lib/security/cacerts
> $ sha512sum ./lib/security/cacerts 
> cf2b4c17161e79001c8e07def3de36c0d523f00a2a6b6e33893a2a3669d930957c11ac765dd29d5ff80e63ad100ef0258291891377f7133b997111ba97b15146  ./lib/security/cacerts
> 
> 
> **Testing**
> 
> - [x] GHA
> - [x] `jdk/tools/jlink` jtreg tests
> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
> 
> Thoughts?

Severin Gehwolf 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:

 - Reboot upgradeable files approach
 - Revert "8353185: Introduce the concept of upgradeable files in context of JEP 493"
   
   This reverts commit bfbfbcb8212ed0f9825549b02b4b52e930c379a7.
 - Merge branch 'master' into jdk-8353185-upgradable-files-jep493
 - 8353185: Introduce the concept of upgradeable files in context of JEP 493

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24388/files
  - new: https://git.openjdk.org/jdk/pull/24388/files/bfbfbcb8..74b6bfe1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24388&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24388&range=00-01

  Stats: 7234 lines in 379 files changed: 4450 ins; 2088 del; 696 mod
  Patch: https://git.openjdk.org/jdk/pull/24388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24388/head:pull/24388

PR: https://git.openjdk.org/jdk/pull/24388

From david.lloyd at redhat.com  Fri Apr  4 15:22:48 2025
From: david.lloyd at redhat.com (David Lloyd)
Date: Fri, 4 Apr 2025 10:22:48 -0500
Subject: RFR: 8348967: Deprecate security permission classes for removal
In-Reply-To: 
References: 
 <9F3RrRIQCRygi1beKlVOjCKbHaF-rDFh63UG1leNDq8=.24f6dca0-e6f6-4fed-ac9a-1355bb73c8be@github.com>
 
 
Message-ID: 

Greetings Daniel,

For the sake of discussion, I will look at these classes as classifiable
into two groups: classes that we use (or are useful) only in the context of
a security manager, and classes that we use (or are useful) independently
of any other JDK API.

I would put all three of these classes (`NetPermission`, `URLPermission`,
and `SocketPermission`) in the former category, as well as the other
non-`AllPermission` classes listed in Sean's PR: we (and our users) would
use them only in the context of a security manager, so when that is gone,
our need to support these classes goes with it, as far as I can tell.

The classes that we would continue to require on an ongoing basis (to my
knowledge) would include `Permission` itself (obviously), `AllPermission`,
and the `BasicPermission` base class (which also seems to be subclassed by
many third-party projects).

On Fri, Apr 4, 2025 at 10:05?AM Daniel Fuchs 
wrote:

> Hi David,
>
> Are there other subclasses of Permission that this framework uses?
> More specifically - would it be fine to deprecate NetPermission,
> URLPermission and SocketPermission classes?
>
> best regards,
>
> -- daniel
>
> On 04/04/2025 15:51, David M. Lloyd wrote:
> >> Can you elaborate or give an example/pointer to code on how it uses
> `AllPermission` w/o the corresponding SM APIs and infrastructure (policy
> files, `AccessController`, etc)?
> >
> > The [`wildfly-elytron`](
> https://github.com/wildfly-security/wildfly-elytron) project uses
> `Permission` and `PermissionCollection` as a standalone basic API to
> represent user authorization permissions. Some examples include
> `LoginPermission` and `RunAsPrincipalPermission`, and a special
> `NoPermission` class which is useful in certain situations.
> >
> > The user authorization mechanism does not use policy files, security
> manager APIs, `AccessController` or any other JAAS-adjacent API for this
> purpose.
> >
> > Security contexts are managed completely separately from the JDK using
> thread local scoping (planned to move to `ScopedValue` someday if/when it
> becomes available). Permissions are checked against the user security
> context (`org.wildfly.security.auth.server.SecurityIdentity`) by
> authorization-sensitive operations in both server and user code.
> >
> > The `AllPermission` class is used for "superuser" authorization
> situations, and cases where the deployer opts out of authorization checks
> for whatever reason (for example, testing). We use it for role-based access
> control of the application server itself when access control checks pass,
> as well for superuser authorization cases, and probably other cases I'm
> forgetting about (it's one of those things that we always assumed would
> stick around forever, so we used it without a second thought).
> >
> > `AllPermission` is an integral concept of permission sets, and thus we
> would be obliged to create our own if the JDK one disappeared, causing
> compatibility problems due to the class moving to a new package from the
> point of view of consumers. Its destiny should be tied to that of
> `Permission` itself in my opinion, because it is pretty fundamental.
> >
> > -------------
> >
> > PR Comment:
> https://git.openjdk.org/jdk/pull/24445#issuecomment-2778956492
>
>

-- 
- DML ? he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From sgehwolf at openjdk.org  Fri Apr  4 15:27:51 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 4 Apr 2025 15:27:51 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493
In-Reply-To: 
References: 
 <9QVEBGTFqMGaocyisN_zUY9mqQtC3mnJoazB0TH0yqU=.6035d751-84b5-4aa3-baf5-e2d02f692565@github.com>
 <_mC3xJvbf0K_Bb4ywZIMUzDFiUzs70vIZz48z43R5-k=.3c8e049b-a869-4cfa-9623-c30ffea6c549@github.com>
 
Message-ID: 

On Fri, 4 Apr 2025 07:55:20 GMT, Alan Bateman  wrote:

>>> Part of me is concerned that the hidden option is a bit of an attractive nuisance. What would you think about just having a fixed list in a properties file in the repo, thus a resource in the jlink module. This would avoid the list in JRTArchive too. It wouldn't rule out introducing something more in the future.
>> 
>> I'm not entirely sure what you are suggesting. Is it keeping a list of "upgradeable" files in a properties file. Files listed in that properties file aren't checked for hash sums (i.e. even if it's not modified)? That is, the explicit opt-in is not needed? Fine by me, but it's a weaker check. If we don't need the explicit opt-in, the patch becomes simpler as well.
>> 
>>> Right now the only examples we have are in java.base. In time it might be that some other modules might need something.
>> 
>> Sure. I've considered that. The `java.base` specific check can go away and it should work for any module as long as we have a list of what's considered an upgradable file (wherever it comes from).
>>  
>>> I've like to know more about cacerts. Are the distros swapping this to a link after the run-time image is created or is it that the sym link is there from the startup and the hashing has followed the link?
>> 
>> Yes, that's one case. For example Fedora/RHEL distros have a `ca-certificates` package which also provides a `cacerts` file consumable from the JDK (`/etc/pki/java/cacerts`). This can be a build-time option, or replaced  with a symlink after the JDK has been built.
>> 
>> Another use case is amending the cacerts store. For example with an enterprise internal CA, in a container. It's really not different to `tzdb.dat`. That too, can be a symlink to a system package or get updated with an external tool after a build.
>> 
>> The option of not following symlinks, isn't an option, though, as certain distro packaging standards require one to install, say man pages - in a specific directory. To keep the JDK image whole, that is usually fixed by placing a symlink back in the JDK image directory.
>
>> I'm not entirely sure what you are suggesting. Is it keeping a list of "upgradeable" files in a properties file. Files listed in that properties file aren't checked for hash sums (i.e. even if it's not modified)? That is, the explicit opt-in is not needed? Fine by me, but it's a weaker check. If we don't need the explicit opt-in, the patch becomes simpler as well.
> 
> Yes, I think keep simple. We always want to allow tzdb.dat be upgraded by the TZ updater tool. I think treating cacerts the same way is okay. As you note, it has to be kept up to date too. I was thinking keytool import and wasn't sure if the Linux distros configure with `-with-cacerts-file` or did something else. Thanks for the clarification on this point.
> 
> Starting with a simple list of two files won't preclude us from re-visiting it again in the future.

@AlanBateman Updated the patch. Please take another look. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2779073478

From sgehwolf at openjdk.org  Fri Apr  4 15:34:50 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 4 Apr 2025 15:34:50 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 4 Apr 2025 15:22:10 GMT, Severin Gehwolf  wrote:

>> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
>> 
>> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
>> 
>> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
>> 2. For those files the hash sum checks are skipped.
>> 
>> **Testing**
>> 
>> - [x] GHA
>> - [x] `jdk/tools/jlink` jtreg tests
>> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
>> 
>> Thoughts?
>
> Severin Gehwolf 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:
> 
>  - Reboot upgradeable files approach
>  - Revert "8353185: Introduce the concept of upgradeable files in context of JEP 493"
>    
>    This reverts commit bfbfbcb8212ed0f9825549b02b4b52e930c379a7.
>  - Merge branch 'master' into jdk-8353185-upgradable-files-jep493
>  - 8353185: Introduce the concept of upgradeable files in context of JEP 493

It took me a while to find the magic trick to get the jlink resource file copied, so adding build-dev for their input too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2779101393

From dfuchs at openjdk.org  Fri Apr  4 15:38:50 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 4 Apr 2025 15:38:50 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
In-Reply-To: 
References: 
Message-ID: <-lk13iK-xcpj57om_W2geIwkx_35JQSE9sKcMzEaMec=.7b41608b-e63d-47ab-aee6-ecdafc2f635f@github.com>

On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan  wrote:

> Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
> 
> The current API note in these classes was reused as the deprecation text. 
> 
> Release Note: https://bugs.openjdk.org/browse/JDK-8353680

Thanks David!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2779110623

From henryjen at openjdk.org  Fri Apr  4 16:03:49 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 4 Apr 2025 16:03:49 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 4 Apr 2025 12:39:47 GMT, Lance Andersen  wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 99:
> 
>> 97:                 if (!entryNames.contains(entryName)) {
>> 98:                     missingEntryNames.add(entryName);
>> 99:                 }
> 
> It looks like you are checking to see if the LOC entry contains within the CEN but I don't see if you are checking if the CEN entry is contained in the LOC
> 
> Another facet of validation is to compare the ordering of entries between the LOC and CEN

Is the ordering required by ZIP or Jar format? We can certainly do that if that's under spec and not an implementation detail.

> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 147:
> 
>> 145:         in incompatible public interfaces
>> 146: warn.validator.duplicate.entry=\
>> 147:         Warning: More than one copy of {0} is detected
> 
> How do we know if the duplicate entry is in the CEN or LOC?

I can add more specific message if that's preferred. I am not expecting user/developer to know about file format details.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2029080880
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2029083361

From henryjen at openjdk.org  Fri Apr  4 16:08:58 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 4 Apr 2025 16:08:58 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 4 Apr 2025 15:59:47 GMT, Henry Jen  wrote:

>> src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 99:
>> 
>>> 97:                 if (!entryNames.contains(entryName)) {
>>> 98:                     missingEntryNames.add(entryName);
>>> 99:                 }
>> 
>> It looks like you are checking to see if the LOC entry contains within the CEN but I don't see if you are checking if the CEN entry is contained in the LOC
>> 
>> Another facet of validation is to compare the ordering of entries between the LOC and CEN
>
> Is the ordering required by ZIP or Jar format? We can certainly do that if that's under spec and not an implementation detail.

As we checking entry uniqueness and  the size match, and all LOC entries should be in CEN, that would means all CEN entries in LOC.
But if we would like to be specific about the inconsistency, then we will have to do a little more work.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2029088848

From lancea at openjdk.org  Fri Apr  4 16:16:48 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 4 Apr 2025 16:16:48 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 4 Apr 2025 16:06:07 GMT, Henry Jen  wrote:

>> Is the ordering required by ZIP or Jar format? We can certainly do that if that's under spec and not an implementation detail.
>
> As we checking entry uniqueness and  the size match, and all LOC entries should be in CEN, that would means all CEN entries in LOC.
> But if we would like to be specific about the inconsistency, then we will have to do a little more work.

Yes, in a perfect world there will be a 1 to 1 match but either way we should sanity check it in case something happened

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2029097428

From lancea at openjdk.org  Fri Apr  4 16:16:49 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 4 Apr 2025 16:16:49 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 4 Apr 2025 16:01:40 GMT, Henry Jen  wrote:

>> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 147:
>> 
>>> 145:         in incompatible public interfaces
>>> 146: warn.validator.duplicate.entry=\
>>> 147:         Warning: More than one copy of {0} is detected
>> 
>> How do we know if the duplicate entry is in the CEN or LOC?
>
> I can add more specific message if that's preferred. I am not expecting user/developer to know about file format details.

It is useful to know where the error is for future analysis

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2029098473

From mullan at openjdk.org  Fri Apr  4 16:22:47 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 4 Apr 2025 16:22:47 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
In-Reply-To: 
References: 
 <9F3RrRIQCRygi1beKlVOjCKbHaF-rDFh63UG1leNDq8=.24f6dca0-e6f6-4fed-ac9a-1355bb73c8be@github.com>
 
Message-ID: 

On Fri, 4 Apr 2025 14:49:36 GMT, David M. Lloyd  wrote:

> `AllPermission` is an integral concept of permission sets, and thus we would be obliged to create our own if the JDK one disappeared, causing compatibility problems due to the class moving to a new package from the point of view of consumers. Its destiny should be tied to that of `Permission` itself in my opinion, because it is pretty fundamental.

Yes, I can see now that this permission is different than the other JDK specific permissions that are being deprecated for removal. I will leave it as-is for now, undeprecated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2779219067

From duke at openjdk.org  Fri Apr  4 16:25:53 2025
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 4 Apr 2025 16:25:53 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
In-Reply-To: 
References: 
Message-ID: 

On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan  wrote:

> Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
> 
> The current API note in these classes was reused as the deprecation text. 
> 
> Release Note: https://bugs.openjdk.org/browse/JDK-8353680

Great, thank you!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2779226283

From rriggs at openjdk.org  Fri Apr  4 16:39:27 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Apr 2025 16:39:27 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v2]
In-Reply-To: 
References: 
Message-ID: <-VbTKqOznNLKI7R7AHZEECmO_Gfu5aYoFpE7T2FriqY=.79b97a1a-1787-465c-b6a8-f590a01c8f9b@github.com>

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Add SuppressWarnings to a Windows source missed earlier.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24444/files
  - new: https://git.openjdk.org/jdk/pull/24444/files/3ae4467e..1fa560a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444

PR: https://git.openjdk.org/jdk/pull/24444

From lancea at openjdk.org  Fri Apr  4 16:47:07 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 4 Apr 2025 16:47:07 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <-zMJMfesQZoXPso7UCC6fE6k0XN3KDtnIjjz7cEB9xQ=.ab47a4df-f3ac-4d00-9328-e29851789bfc@github.com>

On Fri, 4 Apr 2025 16:12:56 GMT, Lance Andersen  wrote:

>> As we checking entry uniqueness and  the size match, and all LOC entries should be in CEN, that would means all CEN entries in LOC.
>> But if we would like to be specific about the inconsistency, then we will have to do a little more work.
>
> Yes, in a perfect world there will be a 1 to 1 match but either way we should sanity check it in case something happened

> Is the ordering required by ZIP or Jar format? We can certainly do that if that's under spec and not an implementation detail.

The Zip Spec states the following:


> 4.3.2 Each file placed into a ZIP file MUST be preceded by  a "local 
>    file header" record for that file.  Each "local file header" MUST be 
>    accompanied by a corresponding "central directory header" record within 
>    the central directory section of the ZIP file.

That being said I am not aware of any implementations  where the order is different given you have to generate the LOC prior to the CEN and End of CEN

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2029133374

From swen at openjdk.org  Fri Apr  4 16:47:19 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 4 Apr 2025 16:47:19 GMT
Subject: RFR: 8353741: Improve UUID.toString performance by using SIMD within a
 register instead of table lookup
Message-ID: 

Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD within a register) instead of table lookup. Eliminating the table lookup can also avoid the performance degradation problem when the cache misses.

-------------

Commit messages:
 - use Long.expand
 - Merge remote-tracking branch 'upstream/master' into optim_uuid_to_string_202501
 - refactor
 - from j3graham
 - add comments
 - use ByteArrayLittleEndian
 - ues Long.expand
 - little endian
 - manual expand
 - Remove unnecessary steps
 - ... and 3 more: https://git.openjdk.org/jdk/compare/37f8e419...1059d39f

Changes: https://git.openjdk.org/jdk/pull/22928/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353741
  Stats: 78 lines in 2 files changed: 47 ins; 27 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22928.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22928/head:pull/22928

PR: https://git.openjdk.org/jdk/pull/22928

From swen at openjdk.org  Fri Apr  4 16:47:19 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 4 Apr 2025 16:47:19 GMT
Subject: RFR: 8353741: Improve UUID.toString performance by using SIMD
 within a register instead of table lookup
In-Reply-To: 
References: 
Message-ID: 

On Mon, 6 Jan 2025 13:18:50 GMT, Shaojin Wen  wrote:

> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD within a register) instead of table lookup. Eliminating the table lookup can also avoid the performance degradation problem when the cache misses.

Under the x64 architecture, performance is significantly improved. However, on some aarch64 platforms, performance regresses.. The performance numbers are as follows:

## 1. Script

git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

# baseline dfaa89162a3
git checkout dfaa89162a35acd20b1ed35e147f9626a181510a
make test TEST="micro:java.util.UUIDBench.toString"

 # current 010ab70c00b
git checkout 010ab70c00b7c0f417127c050654a381b489d052
make test TEST="micro:java.util.UUIDBench.toString"


## 2. aliyun_ecs_c8a_x64 (CPU AMD EPYC? Genoa)

-Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline dfaa89162a3)
-UUIDBench.toString   20000  thrpt   15  84.620 ? 15.957  ops/us

+Benchmark           (size)   Mode  Cnt    Score   Error   Units (current 010ab70c00b)
+UUIDBench.toString   20000  thrpt   15  130.913 ? 0.111  ops/us +54.70%



## 3. aliyun_ecs_c8i_x64 (CPU Intel?Xeon?Emerald Rapids)

-Benchmark           (size)   Mode  Cnt   Score    Error   Units (baseline dfaa89162a3)
-UUIDBench.toString   20000  thrpt   15  84.754 ? 0.291  ops/us

+Benchmark           (size)   Mode  Cnt    Score   Error   Units (current 010ab70c00b)
+UUIDBench.toString   20000  thrpt   15  94.817 ? 0.231  ops/us +11.87%


## 4. aliyun_ecs_c8y_aarch64 (CPU Aliyun Yitian 710)

-Benchmark           (size)   Mode  Cnt   Score   Error   Units (current 010ab70c00b)
-UUIDBench.toString   20000  thrpt   15  70.288 ? 0.147  ops/us

+Benchmark           (size)   Mode  Cnt   Score   Error   Units
+UUIDBench.toString   20000  thrpt   15  92.088 ? 0.137  ops/us +31.01%


## 5. MacBook M1 Pro (aarch64)

-Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline dfaa89162a3)
-UUIDBench.toString   20000  thrpt   15  109.001 ? 0.354  ops/us

+Benchmark           (size)   Mode  Cnt   Score   Error   Units (current 010ab70c00b)
+UUIDBench.toString   20000  thrpt   15  80.671 ? 0.722  ops/us -25.99%


## 6. orange_pi5_aarch64 (CPU RK3588S)

-Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline dfaa89162a3)
-UUIDBench.toString   20000  thrpt   15  37.752 ? 1.430  ops/us

+Benchmark           (size)   Mode  Cnt   Score   Error   Units (current 010ab70c00b)
+UUIDBench.toString   20000  thrpt   15  30.940 ? 1.474  ops/us -18.04



## 7. orange_aipro_aarch64 (CPU TAISHANV200M)

-Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline dfaa89162a3)
-UUIDBench.toString   20000  thrpt   15  13.764 ? 0.262  ops/us

+Benchmark           (size)   Mode  Cnt   Score   Error   Units (current 010ab70c00b)
+UUIDBench.toString   20000  thrpt   15  13.310 ? 0.175  ops/us -3.29%

// Method 1:
i = Long.reverseBytes(Long.expand(i, 0x0F0F_0F0F_0F0F_0F0FL));

// Method 2:
i = ((i & 0xF0000000L) >> 28)
  | ((i & 0xF000000L) >> 16)
  | ((i & 0xF00000L) >> 4)
  | ((i & 0xF0000L) << 8)
  | ((i & 0xF000L) << 20)
  | ((i & 0xF00L) << 32)
  | ((i & 0xF0L) << 44)
  | ((i & 0xFL) << 56);


Note: Using Long.reverseBytes + Long.expand is faster on x64 and ARMv9. 
However, on AArch64 with ARMv8, it will be slower compared to the manual unrolling shown in Method 2.
ARMv8 includes Apple M1/M2, AWS Graviton 3; ARMv9.0 includes Apple M3/M4, Aliyun Yitian 710.

The new implementation improves performance on the aarch64 architecture but results in a performance regression on x64.

## 1. Script

git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

# baseline dfaa89162a3
git checkout dfaa89162a35acd20b1ed35e147f9626a181510a
make test TEST="micro:java.util.UUIDBench.toString"

 # current c513087056b
git checkout c513087056be8c1e1a915625e0b425a7ecbb21d6
make test TEST="micro:java.util.UUIDBench.toString"


## 2. aliyun_ecs_c8a_x64 (CPU AMD EPYC? Genoa)

-Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline dfaa89162a3)
-UUIDBench.toString   20000  thrpt   15  94.274 ? 0.452  ops/us

+Benchmark           (size)   Mode  Cnt   Score   Error   Units (current c513087056b)
+UUIDBench.toString   20000  thrpt   15  80.241 ? 0.894  ops/us -14.88%



## 3. aliyun_ecs_c8i_x64 (CPU Intel?Xeon?Emerald Rapids)

-Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline dfaa89162a3)
-UUIDBench.toString   20000  thrpt   15  85.323 ? 2.044  ops/us

+Benchmark           (size)   Mode  Cnt   Score   Error   Units (current c513087056b)
+UUIDBench.toString   20000  thrpt   15  73.636 ? 0.590  ops/us -13.69%


## 4. aliyun_ecs_c8y_aarch64 (CPU Aliyun Yitian 710)

-Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline dfaa89162a3)
-UUIDBench.toString   20000  thrpt   15  69.286 ? 1.136  ops/us

+Benchmark           (size)   Mode  Cnt   Score   Error   Units (current c513087056b)
+UUIDBench.toString   20000  thrpt   15  80.475 ? 0.310  ops/us +16.14%



## 5. MacBook M1 Pro (aarch64)

-Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline dfaa89162a3)
-UUIDBench.toString   20000  thrpt   15  108.254 ? 1.167  ops/us

+Benchmark           (size)   Mode  Cnt    Score   Error   Units (current c513087056b)
+UUIDBench.toString   20000  thrpt   15  122.313 ? 0.820  ops/us +12.98%



## 6. orange_pi5_aarch64 (CPU RK3588S)

-Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline dfaa89162a3)
-UUIDBench.toString   20000  thrpt   15  37.783 ? 1.553  ops/us

+Benchmark           (size)   Mode  Cnt   Score   Error   Units (current c513087056b)
+UUIDBench.toString   20000  thrpt   15  42.928 ? 2.534  ops/us +13.61%




## 7. orange_aipro_aarch64 (CPU TAISHANV200M)

-Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline dfaa89162a3)
-UUIDBench.toString   20000  thrpt   15  13.822 ? 0.203  ops/us

+Benchmark           (size)   Mode  Cnt   Score   Error   Units (current c513087056b)
+UUIDBench.toString   20000  thrpt   15  18.946 ? 0.156  ops/us +37.07%

Keep it alive.

Keep it alive.

PR #23089 fixes the performance degradation of Long.expand under aarch64. After merging master, this PR uses Long.expand. Tests on various CPUs of x64 and aarch64 show performance improvements, as follows:

## 1. Script

git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

# baseline 3241b4e111e
git checkout 3241b4e111e3dbf475c0e5be117c2a8d1a63ad35
make test TEST="micro:java.util.UUIDBench.toString"

 # current 1059d39f3fb
git checkout 1059d39f3fb3dc58bafb78cf71d387a140130b6f
make test TEST="micro:java.util.UUIDBench.toString"


## 2. aliyun_ecs_c8a_x64 (CPU AMD EPYC? Genoa)

Benchmark           (size)   Mode  Cnt   Score   Error   Units (3241b4e111e)
UUIDBench.toString   20000  thrpt   15  94.372 ? 0.227  ops/us

Benchmark           (size)   Mode  Cnt    Score   Error   Units (1059d39f3fb)
UUIDBench.toString   20000  thrpt   15  116.365 ? 0.405  ops/us +23.30%


## 3. aliyun_ecs_c8i_x64 (CPU Intel?Xeon?Emerald Rapids)

Benchmark           (size)   Mode  Cnt   Score   Error   Units (3241b4e111e)
UUIDBench.toString   20000  thrpt   15  58.594 ? 0.673  ops/us

Benchmark           (size)   Mode  Cnt   Score   Error   Units (1059d39f3fb)
UUIDBench.toString   20000  thrpt   15  61.610 ? 0.677  ops/us +5.14%



## 4. aliyun_ecs_c8y_aarch64 (CPU Aliyun Yitian 710 ARM v9)

Benchmark           (size)   Mode  Cnt   Score   Error   Units (3241b4e111e)
UUIDBench.toString   20000  thrpt   15  69.094 ? 0.615  ops/us

Benchmark           (size)   Mode  Cnt   Score   Error   Units (1059d39f3fb)
UUIDBench.toString   20000  thrpt   15  80.880 ? 0.563  ops/us +17.05%


## 5. MacBook M1 Pro (aarch64)

Benchmark           (size)   Mode  Cnt   Score   Error   Units (3241b4e111e)
UUIDBench.toString   20000  thrpt   15  99.817 ? 2.557  ops/us

Benchmark           (size)   Mode  Cnt    Score   Error   Units (1059d39f3fb)
UUIDBench.toString   20000  thrpt   15  110.155 ? 0.957  ops/us +10.35%


## 6. orange_pi5_aarch64 (CPU RK3588S ARMv8.4)

Benchmark           (size)   Mode  Cnt   Score   Error   Units (3241b4e111e)
UUIDBench.toString   20000  thrpt   15  37.790 ? 1.828  ops/us

Benchmark           (size)   Mode  Cnt   Score   Error   Units (1059d39f3fb)
UUIDBench.toString   20000  thrpt   15  41.086 ? 1.676  ops/us +8.72%


## 7. aws_c8g_aarch64 (CPU Graviton4 ARM v9.0)

Benchmark           (size)   Mode  Cnt   Score   Error   Units (3241b4e111e)
UUIDBench.toString   20000  thrpt   15  78.927 ? 0.683  ops/us

Benchmark           (size)   Mode  Cnt   Score   Error   Units (1059d39f3fb)
UUIDBench.toString   20000  thrpt   15  88.432 ? 0.708  ops/us +12.04%

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22928#issuecomment-2573456774
PR Comment: https://git.openjdk.org/jdk/pull/22928#issuecomment-2577693860
PR Comment: https://git.openjdk.org/jdk/pull/22928#issuecomment-2585077631
PR Comment: https://git.openjdk.org/jdk/pull/22928#issuecomment-2683406127
PR Comment: https://git.openjdk.org/jdk/pull/22928#issuecomment-2708921975
PR Comment: https://git.openjdk.org/jdk/pull/22928#issuecomment-2779245843

From duke at openjdk.org  Fri Apr  4 16:47:19 2025
From: duke at openjdk.org (Johannes Graham)
Date: Fri, 4 Apr 2025 16:47:19 GMT
Subject: RFR: 8353741: Improve UUID.toString performance by using SIMD
 within a register instead of table lookup
In-Reply-To: 
References: 
Message-ID: 

On Mon, 6 Jan 2025 13:18:50 GMT, Shaojin Wen  wrote:

> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD within a register) instead of table lookup. Eliminating the table lookup can also avoid the performance degradation problem when the cache misses.

By stepping through the code of `Long.expand`, and substituting in the constants, I come up with this:


   static long expandNibbles(long i){
        // Inlined version of Long.expand(i,0x0F0F_0F0F_0F0F_0F0FL)
        long t = i << 16;
        i = (i & ~0xFFFF00000000L) | (t & 0xFFFF00000000L);
        t = i << 8;
        i = (i & ~0xFF000000FF0000L) | (t & 0xFF000000FF0000L);
        t = i << 4;
        i = (i & ~0xF000F000F000F00L) | (t & 0xF000F000F000F00L);
        
        return i & 0x0F0F_0F0F_0F0F_0F0FL;
    }


This looks like it might actually do better than *Method 2*.  If inlining and constant folding is happening in  the non-intrinsic `Long.expand` I would imagine it would perform comparably to this.

The non-intrinsified java code should be able to run as quickly as the hand-inlined one.

I think I've found  an issue that prevents the code from being constant-folded as expected. C2 seems to not do constant-folding of xor nodes.

See https://github.com/openjdk/jdk/pull/23089 for an attempt at addressing this.

There are no XOR nodes in expandNibbles
![image](https://github.com/user-attachments/assets/057bc8fc-62a2-4fab-8d56-8e0128dac3cd)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22928#issuecomment-2584577398
PR Comment: https://git.openjdk.org/jdk/pull/22928#issuecomment-2588342173
PR Comment: https://git.openjdk.org/jdk/pull/22928#issuecomment-2590840422

From liach at openjdk.org  Fri Apr  4 16:47:19 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 4 Apr 2025 16:47:19 GMT
Subject: RFR: 8353741: Improve UUID.toString performance by using SIMD
 within a register instead of table lookup
In-Reply-To: 
References: 
Message-ID: 

On Mon, 6 Jan 2025 13:18:50 GMT, Shaojin Wen  wrote:

> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD within a register) instead of table lookup. Eliminating the table lookup can also avoid the performance degradation problem when the cache misses.

Does this expandNibbles compile to any xor nodes in the GVN?

Note that aarch64 has an intrinsic for expand that goes through the vector processing unit. Don't know if that intrinsic or the constant folding takes priority; might need further tweaks to hotspot if that intrinsic comes before the constant folded result and slows things down.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22928#issuecomment-2589380162

From duke at openjdk.org  Fri Apr  4 16:47:19 2025
From: duke at openjdk.org (Johannes Graham)
Date: Fri, 4 Apr 2025 16:47:19 GMT
Subject: RFR: 8353741: Improve UUID.toString performance by using SIMD
 within a register instead of table lookup
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 11 Jan 2025 05:21:36 GMT, Shaojin Wen  wrote:

>> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD within a register) instead of table lookup. Eliminating the table lookup can also avoid the performance degradation problem when the cache misses.
>
> The new implementation improves performance on the aarch64 architecture but results in a performance regression on x64.
> 
> ## 1. Script
> 
> git remote add wenshao git at github.com:wenshao/jdk.git
> git fetch wenshao
> 
> # baseline dfaa89162a3
> git checkout dfaa89162a35acd20b1ed35e147f9626a181510a
> make test TEST="micro:java.util.UUIDBench.toString"
> 
>  # current c513087056b
> git checkout c513087056be8c1e1a915625e0b425a7ecbb21d6
> make test TEST="micro:java.util.UUIDBench.toString"
> 
> 
> ## 2. aliyun_ecs_c8a_x64 (CPU AMD EPYC? Genoa)
> 
> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline dfaa89162a3)
> -UUIDBench.toString   20000  thrpt   15  94.274 ? 0.452  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (current c513087056b)
> +UUIDBench.toString   20000  thrpt   15  80.241 ? 0.894  ops/us -14.88%
> 
> 
> 
> ## 3. aliyun_ecs_c8i_x64 (CPU Intel?Xeon?Emerald Rapids)
> 
> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline dfaa89162a3)
> -UUIDBench.toString   20000  thrpt   15  85.323 ? 2.044  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (current c513087056b)
> +UUIDBench.toString   20000  thrpt   15  73.636 ? 0.590  ops/us -13.69%
> 
> 
> ## 4. aliyun_ecs_c8y_aarch64 (CPU Aliyun Yitian 710)
> 
> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline dfaa89162a3)
> -UUIDBench.toString   20000  thrpt   15  69.286 ? 1.136  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (current c513087056b)
> +UUIDBench.toString   20000  thrpt   15  80.475 ? 0.310  ops/us +16.14%
> 
> 
> 
> ## 5. MacBook M1 Pro (aarch64)
> 
> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline dfaa89162a3)
> -UUIDBench.toString   20000  thrpt   15  108.254 ? 1.167  ops/us
> 
> +Benchmark           (size)   Mode  Cnt    Score   Error   Units (current c513087056b)
> +UUIDBench.toString   20000  thrpt   15  122.313 ? 0.820  ops/us +12.98%
> 
> 
> 
> ## 6. orange_pi5_aarch64 (CPU RK3588S)
> 
> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline dfaa89162a3)
> -UUIDBench.toString   20000  thrpt   15  37.783 ? 1.553  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (current c513087056b)
> +UUIDBench.toString   20000  thrpt   15  42.928 ? 2.534  ops/us +13.61%
> 
> 
> 
> 
> ## 7. orange_aipro_aarch64 (CPU TAISHANV200M)
> 
> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline dfaa89162a3)
> -UUIDBench.toString   20000  thrpt   15  13.822 ? 0.203  ops/us
> 
> +Benchmark           (size)   M...

With regard to the aarch64 vector instrinsic, I don't have access to an aarch64 to try it on (I'm faking it x64 by disabling the intrinsic). @wenshao would it be possible for you to try the Long.expand version of this patch with the patch from https://github.com/openjdk/jdk/pull/23089 to see how aarch64 performs?

> ARMv8 includes Apple M1/M2, AWS Graviton 3; ARMv9.0 includes Apple M3/M4, Aliyun Yitian 710.

An interesting piece of trivia - while the M4 is ARMv9, it appears not to support SVE - in particular the bdep instruction that this code would use. See https://github.com/llvm/llvm-project/blob/14b44179cb61dd551c911dea54de57b588621005/llvm/lib/Target/AArch64/AArch64Processors.td#L923

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22928#issuecomment-2590911374
PR Comment: https://git.openjdk.org/jdk/pull/22928#issuecomment-2614028489

From swen at openjdk.org  Fri Apr  4 16:47:19 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 4 Apr 2025 16:47:19 GMT
Subject: RFR: 8353741: Improve UUID.toString performance by using SIMD
 within a register instead of table lookup
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 14 Jan 2025 19:14:05 GMT, Johannes Graham  wrote:

>> The new implementation improves performance on the aarch64 architecture but results in a performance regression on x64.
>> 
>> ## 1. Script
>> 
>> git remote add wenshao git at github.com:wenshao/jdk.git
>> git fetch wenshao
>> 
>> # baseline dfaa89162a3
>> git checkout dfaa89162a35acd20b1ed35e147f9626a181510a
>> make test TEST="micro:java.util.UUIDBench.toString"
>> 
>>  # current c513087056b
>> git checkout c513087056be8c1e1a915625e0b425a7ecbb21d6
>> make test TEST="micro:java.util.UUIDBench.toString"
>> 
>> 
>> ## 2. aliyun_ecs_c8a_x64 (CPU AMD EPYC? Genoa)
>> 
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline dfaa89162a3)
>> -UUIDBench.toString   20000  thrpt   15  94.274 ? 0.452  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (current c513087056b)
>> +UUIDBench.toString   20000  thrpt   15  80.241 ? 0.894  ops/us -14.88%
>> 
>> 
>> 
>> ## 3. aliyun_ecs_c8i_x64 (CPU Intel?Xeon?Emerald Rapids)
>> 
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline dfaa89162a3)
>> -UUIDBench.toString   20000  thrpt   15  85.323 ? 2.044  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (current c513087056b)
>> +UUIDBench.toString   20000  thrpt   15  73.636 ? 0.590  ops/us -13.69%
>> 
>> 
>> ## 4. aliyun_ecs_c8y_aarch64 (CPU Aliyun Yitian 710)
>> 
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline dfaa89162a3)
>> -UUIDBench.toString   20000  thrpt   15  69.286 ? 1.136  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (current c513087056b)
>> +UUIDBench.toString   20000  thrpt   15  80.475 ? 0.310  ops/us +16.14%
>> 
>> 
>> 
>> ## 5. MacBook M1 Pro (aarch64)
>> 
>> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline dfaa89162a3)
>> -UUIDBench.toString   20000  thrpt   15  108.254 ? 1.167  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt    Score   Error   Units (current c513087056b)
>> +UUIDBench.toString   20000  thrpt   15  122.313 ? 0.820  ops/us +12.98%
>> 
>> 
>> 
>> ## 6. orange_pi5_aarch64 (CPU RK3588S)
>> 
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline dfaa89162a3)
>> -UUIDBench.toString   20000  thrpt   15  37.783 ? 1.553  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (current c513087056b)
>> +UUIDBench.toString   20000  thrpt   15  42.928 ? 2.534  ops/us +13.61%
>> 
>> 
>> 
>> 
>> ## 7. orange_aipro_aarch64 (CPU TAISHANV200M)
>> 
>> -Benchmark           (size)   Mode  Cnt   Sco...
>
> With regard to the aarch64 vector instrinsic, I don't have access to an aarch64 to try it on (I'm faking it x64 by disabling the intrinsic). @wenshao would it be possible for you to try the Long.expand version of this patch with the patch from https://github.com/openjdk/jdk/pull/23089 to see how aarch64 performs?

@j3graham
 Based on PR 23089, there has been a noticeable performance improvement in xor_const, except on AWS C7g (AArch64) machines.

## 1. Script

git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

# baseline dfaa89162a3
git checkout dfaa89162a35acd20b1ed35e147f9626a181510a
make test TEST="micro:java.util.UUIDBench.toString"

 # current c513087056b
git checkout c513087056be8c1e1a915625e0b425a7ecbb21d6
make test TEST="micro:java.util.UUIDBench.toString"

# xor_const + Long.expand 4f54ac68a9f
git checkout 4f54ac68a9fdb635ea2a3f03787cbf0d052dac25
make test TEST="micro:java.util.UUIDBench.toString"


## 2. aliyun_ecs_c8a_x64 (CPU AMD EPYC? Genoa)

Benchmark           (size)   Mode  Cnt   Score   Error   Units (dfaa89162a3)
UUIDBench.toString   20000  thrpt   15  94.273 ? 0.196  ops/us

Benchmark           (size)   Mode  Cnt   Score   Error   Units (c513087056b)
UUIDBench.toString   20000  thrpt   15  79.701 ? 0.979  ops/us

Benchmark           (size)   Mode  Cnt    Score   Error   Units (4f54ac68a9f)
UUIDBench.toString   20000  thrpt   15  131.954 ? 1.005  ops/us



## 3. aliyun_ecs_c8i_x64 (CPU Intel?Xeon?Emerald Rapids)

Benchmark           (size)   Mode  Cnt    Score   Error   Units (dfaa89162a3)
UUIDBench.toString   20000  thrpt   15  110.221 ? 4.370  ops/us

Benchmark           (size)   Mode  Cnt   Score   Error   Units (c513087056b)
UUIDBench.toString   20000  thrpt   15  78.233 ? 0.790  ops/us

Benchmark           (size)   Mode  Cnt    Score   Error   Units (4f54ac68a9f)
UUIDBench.toString   20000  thrpt   15  136.119 ? 0.464  ops/us


## 4. aliyun_ecs_c8y_aarch64 (CPU Aliyun Yitian 710 ARM v9)

Benchmark           (size)   Mode  Cnt   Score   Error   Units (dfaa89162a3)
UUIDBench.toString   20000  thrpt   15  70.538 ? 0.095  ops/us

Benchmark           (size)   Mode  Cnt   Score   Error   Units (c513087056b)
UUIDBench.toString   20000  thrpt   15  80.501 ? 0.280  ops/us

Benchmark           (size)   Mode  Cnt   Score   Error   Units (4f54ac68a9f)
UUIDBench.toString   20000  thrpt   15  93.289 ? 0.665  ops/us



## 5. MacBook M1 Pro (aarch64)

Benchmark           (size)   Mode  Cnt    Score   Error   Units (dfaa89162a3)
UUIDBench.toString   20000  thrpt   15  106.552 ? 0.856  ops/us

Benchmark           (size)   Mode  Cnt    Score   Error   Units (c513087056b)
UUIDBench.toString   20000  thrpt   15  120.775 ? 0.755  ops/us

Benchmark           (size)   Mode  Cnt    Score   Error   Units (4f54ac68a9f)
UUIDBench.toString   20000  thrpt   15  121.762 ? 0.826  ops/us



## 6. orange_pi5_aarch64 (CPU RK3588S ARMv8.4)

Benchmark           (size)   Mode  Cnt   Score   Error   Units (dfaa89162a3)
UUIDBench.toString   20000  thrpt   15  37.314 ? 1.616  ops/us

Benchmark           (size)   Mode  Cnt   Score   Error   Units (c513087056b)
UUIDBench.toString   20000  thrpt   15  43.791 ? 2.181  ops/us

Benchmark           (size)   Mode  Cnt   Score   Error   Units (4f54ac68a9f)
UUIDBench.toString   20000  thrpt   15  43.906 ? 1.287  ops/us




## 7. aws_c7g_aarch64 (CPU Graviton3 ARMv8.4)

Benchmark           (size)   Mode  Cnt   Score   Error   Units (dfaa89162a3)
UUIDBench.toString   20000  thrpt   15  65.280 ? 0.742  ops/us


Benchmark           (size)   Mode  Cnt   Score   Error   Units (c513087056b)
UUIDBench.toString   20000  thrpt   15  59.123 ? 0.338  ops/us

Benchmark           (size)   Mode  Cnt   Score   Error   Units (4f54ac68a9f)
UUIDBench.toString   20000  thrpt   15  58.846 ? 0.729  ops/us



## 8. aws_c8g_aarch64 (CPU Graviton4 ARM v9.0)

Benchmark           (size)   Mode  Cnt   Score   Error   Units (dfaa89162a3)
UUIDBench.toString   20000  thrpt   15  81.226 ? 0.374  ops/us

Benchmark           (size)   Mode  Cnt   Score   Error   Units (c513087056b)
UUIDBench.toString   20000  thrpt   15  87.328 ? 1.086  ops/us

Benchmark           (size)   Mode  Cnt   Score   Error   Units (4f54ac68a9f)
UUIDBench.toString   20000  thrpt   15  93.546 ? 1.623  ops/us



## 9. orange_aipro_aarch64 (CPU TAISHANV200M)


Benchmark           (size)   Mode  Cnt   Score   Error   Units (dfaa89162a3)
UUIDBench.toString   20000  thrpt   15  13.828 ? 0.142  ops/us


Benchmark           (size)   Mode  Cnt   Score   Error   Units (c513087056b)
UUIDBench.toString   20000  thrpt   15  18.870 ? 0.251  ops/us

Benchmark           (size)   Mode  Cnt   Score   Error   Units (4f54ac68a9f)
UUIDBench.toString   20000  thrpt   15  18.833 ? 0.192  ops/us

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22928#issuecomment-2593333971

From swen at openjdk.org  Fri Apr  4 16:51:51 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 4 Apr 2025 16:51:51 GMT
Subject: RFR: 8353741: Improve UUID.toString performance by using SIMD
 within a register instead of table lookup [v2]
In-Reply-To: 
References: 
Message-ID: <6CSwv7GpIss5uEdZRHWQCAASfCpN9uknToBbtt5XZPc=.b580edc0-063f-4954-a2f3-936c0b57f98f@github.com>

> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD within a register) instead of table lookup. Eliminating the table lookup can also avoid the performance degradation problem when the cache misses.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22928/files
  - new: https://git.openjdk.org/jdk/pull/22928/files/1059d39f..93d283e4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22928.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22928/head:pull/22928

PR: https://git.openjdk.org/jdk/pull/22928

From jai.forums2013 at gmail.com  Fri Apr  4 16:55:04 2025
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Fri, 4 Apr 2025 22:25:04 +0530
Subject: Add "SHA-384" as a known attribute
In-Reply-To: 
References: 
Message-ID: <6b6c44dd-65ca-4f77-a204-bd2dd8dcbd61@gmail.com>

Since this is about caching values in the java.util.jar.Attributes 
class, the discussion is more appropriate in the core-libs-dev mailing 
list. I've added it to the "To" now and "Bcc"ed the jdk-dev mailing 
list. Please subscribe to core-libs-dev 
https://mail.openjdk.org/mailman/listinfo/core-libs-dev if you haven't 
already and we can continue the discussion there.

-Jaikiran

On 04/04/25 8:54 pm, Ayman wrote:
> Hello,
>
> Starting from JDK 19, SHA-384 is replacing SHA-256 as the default 
> digest algorithm in the jarsigner: 
> https://bugs.openjdk.org/browse/JDK-8283475
>
> This means that the string "SHA-384" is now written multiples times is 
> the MANIFEST files, this has been tackled in the past by adding the 
> string "SHA-256" as a KNOWN_NAME that shouldn't be duplicated in 
> memory: 
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/jar/Attributes.java#L729 
>
>
> Is it possible to do the same with "SHA-384"?
>
> Thanks,

From jengebr at amazon.com  Fri Apr  4 16:57:45 2025
From: jengebr at amazon.com (Engebretson, John)
Date: Fri, 4 Apr 2025 16:57:45 +0000
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: <426eefbde9c946daaca00c9829d87c2b@amazon.com>
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 
 <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 
 
 <146bdb36-07bb-4bd9-8394-f5db20d6e4e9@oracle.com>
 <426eefbde9c946daaca00c9829d87c2b@amazon.com>
Message-ID: 

  I?ve split the unsynchronized BAOS into its own issue, JDK-8353729, which shows performance improvements on primitive writes.  MemoryOutputStream remains superior in that case and others.
     John

From: Engebretson, John
Sent: Thursday, April 3, 2025 7:45 AM
To: 'Alan Bateman' ; Markus KARG ; core-libs-dev at openjdk.org
Subject: RE: [EXTERNAL] JDK-8352891 Performance improvements to ByteArrayOutputStream

  I certainly see the value in the unsynchronized variant and am happy to do that ? but that isn?t sufficient to address the original problem of scaling the array.  MemoryOutputStream results in 3x improvement and eliminates the hard 2GB cap, and can replace custom logic in Tomcat, Spring, etc.  What?s our next move there?
  Thanks!  ?
     John

From: Alan Bateman >
Sent: Thursday, April 3, 2025 3:18 AM
To: Engebretson, John >; Markus KARG >; core-libs-dev at openjdk.org
Subject: RE: [EXTERNAL] JDK-8352891 Performance improvements to ByteArrayOutputStream


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


On 02/04/2025 19:04, Engebretson, John wrote:
  Apologies, human error ? here?s the message I intended:

  Thank you!  I?ve updated the PR accordingly and summarized the benchmarks in the description.  Here?s the short version:

  1.  For small payloads, unsynchronized and optimized versions are 2-4x faster than base
  2.  For large payloads, optimized version is 3x faster than base or unsynchronized

  I discovered a capacity-related incompatibility between ByteArrayOutputStream and MemoryOutputStream: the size() method returns int, but MemoryOutputStream can exceed that value.  I added range checking to size() and a new sizeAsLong() method? but it really makes me wonder MemoryOutputStream belongs as a subclass of ByteArrayOutputStream.  It now has two significant incompatibilities: ignoring the protected fields, and size restrictions.

The protected fields are only accessible to subclasses so it's not an issue. BAOS::toByteArray (in addition to size) means the entire content must fit into a byte[]. A sink capable of accumulating but bytes that this is a different API.

I think we should at least pursue ByteArrayOutputStream.unsynchronized(int cap) and work through the javadoc changes to allow that. It does not need to use buf, we have flexibility on how the bytes are buffered.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dnawab at outlook.com  Fri Apr  4 16:58:05 2025
From: dnawab at outlook.com (Danish Nawab)
Date: Fri, 4 Apr 2025 16:58:05 +0000
Subject: Usage feedback: jnativescan
Message-ID: 

jnativescan terminates when ran on a JAR with a missing class.
Example:

```
jnativescan --class-path reactor-core-3.7.4.jar

ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String
CAUSED BY: System class can not be found: sun.misc.JavaLangAccess
```

(above jar downloaded from [1])

The offending class seems to refer to a now unavailable sun.misc.JavaLangAccess but still handles this error scenario silently [2]

Because jnativescan terminates early, I can't say whether or not this library uses native/restricted features. Perhaps it would be better if instead of terminating, jnativescan continued the analysis after warning about the missing class.

Also, the above JAR seems to be a Multi-Release Jar, where the Java 11+ version of the code does not even refer sun.misc.JavaLangAccess [3].
Should jnativescan have special handling for Multi-Release JARs by analysing the version that would be applicable for the current JDK?

Versions:
```
java --version
openjdk 24 2025-03-18
OpenJDK Runtime Environment (build 24+36-3646)
OpenJDK 64-Bit Server VM (build 24+36-3646, mixed mode, sharing)

jnativescan --version
24
```

Overall, jnativescan is extremely helpful in finding the dependencies using native/restricted features.

[1] https://repo1.maven.org/maven2/io/projectreactor/reactor-core/3.7.4/reactor-core-3.7.4.jar
[2] https://github.com/reactor/reactor-core/blob/7dee739/reactor-core/src/main/java/reactor/core/publisher/CallSiteSupplierFactory.java#L56-L64
[3] https://github.com/reactor/reactor-core/blob/0b93178/reactor-core/src/main/java11/reactor/core/publisher/CallSiteSupplierFactory.java

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jai.forums2013 at gmail.com  Fri Apr  4 17:05:38 2025
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Fri, 4 Apr 2025 22:35:38 +0530
Subject: Add "SHA-384" as a known attribute
In-Reply-To: <6b6c44dd-65ca-4f77-a204-bd2dd8dcbd61@gmail.com>
References: 
 <6b6c44dd-65ca-4f77-a204-bd2dd8dcbd61@gmail.com>
Message-ID: <07cc31e5-98f1-49bd-829c-de625216aa6c@gmail.com>

The caching of some attribute names in the java.util.jar.Attributes 
class appears to have been introduced in 
https://bugs.openjdk.org/browse/JDK-6805750 (RFR 
https://mail.openjdk.org/pipermail/core-libs-dev/2018-April/052697.html).

Given the precedence, it may be OK to add "SHA-384-Digest" to that set, 
but I don't know how much (if any) would it help with the performance. 
Did you happen to notice any performance issues which prompted you to 
look at this cache?

-Jaikiran

On 04/04/25 10:25 pm, Jaikiran Pai wrote:
> Since this is about caching values in the java.util.jar.Attributes 
> class, the discussion is more appropriate in the core-libs-dev mailing 
> list. I've added it to the "To" now and "Bcc"ed the jdk-dev mailing 
> list. Please subscribe to core-libs-dev 
> https://mail.openjdk.org/mailman/listinfo/core-libs-dev if you haven't 
> already and we can continue the discussion there.
>
> -Jaikiran
>
> On 04/04/25 8:54 pm, Ayman wrote:
>> Hello,
>>
>> Starting from JDK 19, SHA-384 is replacing SHA-256 as the default 
>> digest algorithm in the jarsigner: 
>> https://bugs.openjdk.org/browse/JDK-8283475
>>
>> This means that the string "SHA-384" is now written multiples times 
>> is the MANIFEST files, this has been tackled in the past by adding 
>> the string "SHA-256" as a KNOWN_NAME that shouldn't be duplicated in 
>> memory: 
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/jar/Attributes.java#L729 
>>
>>
>> Is it possible to do the same with "SHA-384"?
>>
>> Thanks,

From naoto at openjdk.org  Fri Apr  4 17:28:48 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 4 Apr 2025 17:28:48 GMT
Subject: RFR: 8353585: Provide ChoiceFormat#parse(String,
 ParsePosition) tests [v2]
In-Reply-To: <-E75OTUgSbq54CMgK9DU8KTqorFvDlY2xOg6Fr9L8yk=.982f252e-b74b-47f3-a483-5feb484e7ff7@github.com>
References: 
 <-E75OTUgSbq54CMgK9DU8KTqorFvDlY2xOg6Fr9L8yk=.982f252e-b74b-47f3-a483-5feb484e7ff7@github.com>
Message-ID: 

On Thu, 3 Apr 2025 21:23:08 GMT, Justin Lu  wrote:

>> Please review this PR which provides unit tests for `ChoiceFormat#parse(String, ParsePosition)` to check default, multi match, and no match behavior. There were no existing relevant tests.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naoto's review - neg and exceeding length PP index cases

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24395#pullrequestreview-2743694201

From mullan at openjdk.org  Fri Apr  4 18:04:39 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 4 Apr 2025 18:04:39 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
> 
> The current API note in these classes was reused as the deprecation text. 
> 
> Release Note: https://bugs.openjdk.org/browse/JDK-8353680

Sean Mullan has updated the pull request incrementally with three additional commits since the last revision:

 - Merge branch 'JDK-8348967' of gh:seanjmullan/jdk into JDK-8348967
 - Revert "Initial revision."
   Undeprecate AllPermission.
   
   This reverts commit 38938d9d56672ecc374c3d86a891c95e6b164d02.
 - Remove trailing whitespace.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24445/files
  - new: https://git.openjdk.org/jdk/pull/24445/files/de5f360e..8dae2f8d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24445&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24445&range=00-01

  Stats: 19 lines in 8 files changed: 0 ins; 15 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24445.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24445/head:pull/24445

PR: https://git.openjdk.org/jdk/pull/24445

From tpushkin at openjdk.org  Fri Apr  4 18:16:19 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 4 Apr 2025 18:16:19 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v3]
In-Reply-To: 
References: 
Message-ID: 

> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app.
> 
> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible.
> 
> Implementation note: `URLClassLoader` does not allow selecting a specific URL to load a specific class ? I used reflection to override a private part of `URLClassLoader` responsible for URL selection while being able to use the rest of its implementation.

Timofei Pushkin has updated the pull request incrementally with two additional commits since the last revision:

 - Make getResource concurrent-friendly
 - Don't use URLClassLoader

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24223/files
  - new: https://git.openjdk.org/jdk/pull/24223/files/784c1a83..5db07cef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=01-02

  Stats: 57 lines in 2 files changed: 4 ins; 37 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/24223.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223

PR: https://git.openjdk.org/jdk/pull/24223

From tpushkin at openjdk.org  Fri Apr  4 18:16:19 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 4 Apr 2025 18:16:19 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v3]
In-Reply-To: <4h_JVYUvsLEwiafAxd4sSY6DsjlCZIHq_bE03wK4nuw=.707f5fc0-6b63-428d-9c21-0cccc8508ff6@github.com>
References: 
 <4h_JVYUvsLEwiafAxd4sSY6DsjlCZIHq_bE03wK4nuw=.707f5fc0-6b63-428d-9c21-0cccc8508ff6@github.com>
Message-ID: 

On Fri, 4 Apr 2025 05:58:47 GMT, Ioi Lam  wrote:

>> Timofei Pushkin has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Make getResource concurrent-friendly
>>  - Don't use URLClassLoader
>
> src/java.base/share/classes/jdk/internal/misc/CDS.java line 446:
> 
>> 444:         protected Class findClass(String name) throws ClassNotFoundException {
>> 445:             // Unregistered classes should be found in load(...), registered classes should be
>> 446:             // handeled by parent loaders
> 
> This does seem like a good simplification, as we no longer need to check the `currentClassName`, `currentSuperClass`, etc. 
> 
> We had a plan for supported multiple classes for the same name, but we never go around doing it (even though the classlist format supports that with the use of IDs).
> 
> I am not sure if the current tests includes a case where a class name `Foo` exists both in the classpath as well as in a custom loader. If not, I think we should add such a case (to ensure that UnregisteredClassLoader never delegates to the application class loader and finds the wrong `Foo`).

Thank you for the review!

> We had a plan for supported multiple classes for the same name, but we never go around doing it (even though the classlist format supports that with the use of IDs).

With this approach having multiple unregistered classes with the same name is not possible (JVM will not allow this for a single class loader) so if you are still planning to support this in the near future it would be better to go with the approach originally suggested in the issue: continue using multiple unregistered class loaders but record class loader ID in class list and create only one archiving class loader per recorded ID. But that would be a larger change since it requires class list format to be changed.

> I am not sure if the current tests includes a case where a class name Foo exists both in the classpath as well as in a custom loader

Pre-existing `ClassFromSystemModule` test seems to test the boot classpath case. I've also added a new test for the app classpath case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2029248783

From tpushkin at openjdk.org  Fri Apr  4 18:19:54 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Fri, 4 Apr 2025 18:19:54 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v3]
In-Reply-To: <4h_JVYUvsLEwiafAxd4sSY6DsjlCZIHq_bE03wK4nuw=.707f5fc0-6b63-428d-9c21-0cccc8508ff6@github.com>
References: 
 <4h_JVYUvsLEwiafAxd4sSY6DsjlCZIHq_bE03wK4nuw=.707f5fc0-6b63-428d-9c21-0cccc8508ff6@github.com>
Message-ID: 

On Fri, 4 Apr 2025 06:15:27 GMT, Ioi Lam  wrote:

>> Timofei Pushkin has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Make getResource concurrent-friendly
>>  - Don't use URLClassLoader
>
> src/java.base/share/classes/jdk/internal/misc/CDS.java line 420:
> 
>> 418:                 // class loader. Thus it is safe to delegate their loading to system class loader
>> 419:                 // (our parent) - this is what the default implementation of loadClass() will do.
>> 420:                 return (Class) DEFINE_CLASS.invoke(this, name, res);
> 
> Instead of subclassing from `URLClassLoader` and go through the trouble of calling its `defineClass()` method, maybe we should just subclass from `ClassLoader` and maintain a hashtable of java.util.jar.JarFiles.
> 
> 
> HashMap map = ....;
> JarFile jar = map.get(source) ... or open a new JarFile if not found
> byte[] buffer = read jar file for the given class name;
> call ClassLoader.defineClass(buffer, ...)

All the opening and reading is handled by `URLClassPath` (it's not just JARs, can also be directories). I used only `defineClass` from `URLClassLoader` to minimize the behavior difference with the old code ? besides defining the class it defines its package and protection domain. But it looks like static CDS strips these anyway, so I've removed `URLClassLoader` entirely.

`URLClassPath` usage can also be removed ? then the small addition to it from this PR won't be needed but its functionality will be somewhat duplicated in `CDS.UnregisteredLoader`. I've implemented this [in a separate branch](https://github.com/openjdk/jdk/compare/master...TimPushkin:jdk:one-loader-v2?expand=1).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2029253444

From rriggs at openjdk.org  Fri Apr  4 18:21:29 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Apr 2025 18:21:29 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v3]
In-Reply-To: 
References: 
Message-ID: 

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Updated style of @Deprecated to match most existing @Deprecated annotations
  `since` comes before `forRemoval`
  No spaces around `=`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24444/files
  - new: https://git.openjdk.org/jdk/pull/24444/files/1fa560a4..bb18c1e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=01-02

  Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444

PR: https://git.openjdk.org/jdk/pull/24444

From elmoussaoui.ayman01 at gmail.com  Fri Apr  4 18:25:18 2025
From: elmoussaoui.ayman01 at gmail.com (Ayman)
Date: Fri, 4 Apr 2025 20:25:18 +0200
Subject: Add "SHA-384" as a known attribute
In-Reply-To: <07cc31e5-98f1-49bd-829c-de625216aa6c@gmail.com>
References: 
 <6b6c44dd-65ca-4f77-a204-bd2dd8dcbd61@gmail.com>
 <07cc31e5-98f1-49bd-829c-de625216aa6c@gmail.com>
Message-ID: 

Yes, I started looking into this because of a memory regression.
While upgrading our project from Java 17 to Java 21, I noticed an increase
in memory consumption. After dumping the heap and analyzing the
differences, I found that there are a few thousand instances of the class
"java.util.jar.Attributes$Name" which all contain the same string which is
"SHA-384-Digest".
In our case, it was a 2MB increase in a process that uses 35MB normally so
that's almost a 5% increase.
The issue here is that we are loading multiple jars that each contain a
MANIFEST file which contains hundreds of classes and so many times the
string "SHA-384-Digest".

It would be nice if the fix could be backported to java 21 since it's the
current LTS that's impacted.

On Fri, Apr 4, 2025 at 7:07?PM Jaikiran Pai 
wrote:

> The caching of some attribute names in the java.util.jar.Attributes
> class appears to have been introduced in
> https://bugs.openjdk.org/browse/JDK-6805750 (RFR
> https://mail.openjdk.org/pipermail/core-libs-dev/2018-April/052697.html).
>
> Given the precedence, it may be OK to add "SHA-384-Digest" to that set,
> but I don't know how much (if any) would it help with the performance.
> Did you happen to notice any performance issues which prompted you to
> look at this cache?
>
> -Jaikiran
>
> On 04/04/25 10:25 pm, Jaikiran Pai wrote:
> > Since this is about caching values in the java.util.jar.Attributes
> > class, the discussion is more appropriate in the core-libs-dev mailing
> > list. I've added it to the "To" now and "Bcc"ed the jdk-dev mailing
> > list. Please subscribe to core-libs-dev
> > https://mail.openjdk.org/mailman/listinfo/core-libs-dev if you haven't
> > already and we can continue the discussion there.
> >
> > -Jaikiran
> >
> > On 04/04/25 8:54 pm, Ayman wrote:
> >> Hello,
> >>
> >> Starting from JDK 19, SHA-384 is replacing SHA-256 as the default
> >> digest algorithm in the jarsigner:
> >> https://bugs.openjdk.org/browse/JDK-8283475
> >>
> >> This means that the string "SHA-384" is now written multiples times
> >> is the MANIFEST files, this has been tackled in the past by adding
> >> the string "SHA-256" as a KNOWN_NAME that shouldn't be duplicated in
> >> memory:
> >>
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/jar/Attributes.java#L729
> >>
> >>
> >> Is it possible to do the same with "SHA-384"?
> >>
> >> Thanks,
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rriggs at openjdk.org  Fri Apr  4 18:26:50 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Apr 2025 18:26:50 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
 [v2]
In-Reply-To: 
References: 
 
Message-ID: <4U4fHTMkZq09NuiU-svQOicKoYLqEMUmIyUcNZnTNgw=.09aa34d1-23a7-4c76-8050-727875c54ffe@github.com>

On Fri, 4 Apr 2025 18:04:39 GMT, Sean Mullan  wrote:

>> Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
>> 
>> The current API note in these classes was reused as the deprecation text. 
>> 
>> Release Note: https://bugs.openjdk.org/browse/JDK-8353680
>
> Sean Mullan has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Merge branch 'JDK-8348967' of gh:seanjmullan/jdk into JDK-8348967
>  - Revert "Initial revision."
>    Undeprecate AllPermission.
>    
>    This reverts commit 38938d9d56672ecc374c3d86a891c95e6b164d02.
>  - Remove trailing whitespace.

Looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24445#pullrequestreview-2743809469

From iris at openjdk.org  Fri Apr  4 18:33:58 2025
From: iris at openjdk.org (Iris Clark)
Date: Fri, 4 Apr 2025 18:33:58 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
 [v2]
In-Reply-To: 
References: 
 
Message-ID: <5KYDV4UYQqtRvB8n6oeHBpCV5MhrsKSQWsAjC_Rotg8=.28c75b48-6362-4970-96f8-b9f104e25d2a@github.com>

On Fri, 4 Apr 2025 18:04:39 GMT, Sean Mullan  wrote:

>> Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
>> 
>> The current API note in these classes was reused as the deprecation text. 
>> 
>> Release Note: https://bugs.openjdk.org/browse/JDK-8353680
>
> Sean Mullan has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Merge branch 'JDK-8348967' of gh:seanjmullan/jdk into JDK-8348967
>  - Revert "Initial revision."
>    Undeprecate AllPermission.
>    
>    This reverts commit 38938d9d56672ecc374c3d86a891c95e6b164d02.
>  - Remove trailing whitespace.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24445#pullrequestreview-2743822700

From iris at openjdk.org  Fri Apr  4 18:40:50 2025
From: iris at openjdk.org (Iris Clark)
Date: Fri, 4 Apr 2025 18:40:50 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v3]
In-Reply-To: 
References: 
 
Message-ID: <9XnN5LLqYWAbbv3Smz9WTvMTZcbGwpGnQJtozSQm0Co=.ba9516ba-7fdc-4694-88e4-93a78a788099@github.com>

On Fri, 4 Apr 2025 18:21:29 GMT, Roger Riggs  wrote:

>> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
>> 
>> @Deprecated(forRemoval = true, since="25")
>> Is added to each class and the existing @apiNote is converted to @deprected
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated style of @Deprecated to match most existing @Deprecated annotations
>   `since` comes before `forRemoval`
>   No spaces around `=`

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24444#pullrequestreview-2743835110

From rriggs at openjdk.org  Fri Apr  4 19:00:02 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Apr 2025 19:00:02 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v4]
In-Reply-To: 
References: 
Message-ID: 

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused import of LinkPermission

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24444/files
  - new: https://git.openjdk.org/jdk/pull/24444/files/bb18c1e6..25aa6099

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444

PR: https://git.openjdk.org/jdk/pull/24444

From mullan at openjdk.org  Fri Apr  4 19:07:59 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 4 Apr 2025 19:07:59 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 4 Apr 2025 19:00:02 GMT, Roger Riggs  wrote:

>> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
>> 
>> @Deprecated(forRemoval = true, since="25")
>> Is added to each class and the existing @apiNote is converted to @deprected
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused import of LinkPermission

Some copyright dates have not been updated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24444#issuecomment-2779539268

From rriggs at openjdk.org  Fri Apr  4 19:15:29 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Apr 2025 19:15:29 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v5]
In-Reply-To: 
References: 
Message-ID: 

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright in WindowsFileCopy

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24444/files
  - new: https://git.openjdk.org/jdk/pull/24444/files/25aa6099..c1457493

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444

PR: https://git.openjdk.org/jdk/pull/24444

From mullan at openjdk.org  Fri Apr  4 19:15:29 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 4 Apr 2025 19:15:29 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 4 Apr 2025 19:00:02 GMT, Roger Riggs  wrote:

>> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
>> 
>> @Deprecated(forRemoval = true, since="25")
>> Is added to each class and the existing @apiNote is converted to @deprected
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused import of LinkPermission

src/java.base/share/classes/java/io/FilePermission.java line 87:

> 85: 
> 86: @Deprecated(since="25", forRemoval=true)
> 87: @SuppressWarnings("removal")

Is this leftover? You already add it to the methods that need it.

src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 202:

> 200:     }
> 201: 
> 202:     @SuppressWarnings("removal")

This should not be necessary.

src/java.logging/share/classes/java/util/logging/LoggingPermission.java line 48:

> 46:  */
> 47: 
> 48: @Deprecated(forRemoval = true, since="25")

This order is different than other classes, maybe make it consistent?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2029312409
PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2029308725
PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2029311303

From rriggs at openjdk.org  Fri Apr  4 19:22:46 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Apr 2025 19:22:46 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v6]
In-Reply-To: 
References: 
Message-ID: 

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary SuppressWarnings and correct Deprecated annotation style

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24444/files
  - new: https://git.openjdk.org/jdk/pull/24444/files/c1457493..9a9417a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=04-05

  Stats: 3 lines in 3 files changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444

PR: https://git.openjdk.org/jdk/pull/24444

From brian.burkhalter at oracle.com  Fri Apr  4 20:31:10 2025
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 4 Apr 2025 20:31:10 +0000
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 
 <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
Message-ID: 

I did not notice that Alan?s comment below, about adding a hint as to the maximum expected size, has been specifically addressed anywhere in this discussion. It might not be all that pertinent to the main thread of discussion, however, but it would certainly be useful for the issue [1], which I linked to [2].

Brian

[1] https://bugs.openjdk.org/browse/JDK-8329287
[2] https://bugs.openjdk.org/browse/JDK-8353729

On Apr 2, 2025, at 3:52?AM, Alan Bateman  wrote:

[?] and whether having a parameter to specify the initial size or some hint of the max size would help the discussion.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Fri Apr  4 21:12:14 2025
From: duke at openjdk.org (ExE Boss)
Date: Fri, 4 Apr 2025 21:12:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v41]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 4 Apr 2025 09:14:22 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments on docs

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 65:

> 63:     // | null           |  Unset        |
> 64:     // | nullSentinel() |  Set(null)    |
> 65:     // | other          |  Set(other)   |

There?is no?longer any?method?called `nullSentinel()`:
Suggestion:

    // | Value         |  Meaning      |
    // | ------------- |  ------------ |
    // | null          |  Unset        |
    // | NULL_SENTINEL |  Set(null)    |
    // | other         |  Set(other)   |

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2029434983

From iklam at openjdk.org  Fri Apr  4 21:14:53 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 4 Apr 2025 21:14:53 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v3]
In-Reply-To: 
References: 
 <4h_JVYUvsLEwiafAxd4sSY6DsjlCZIHq_bE03wK4nuw=.707f5fc0-6b63-428d-9c21-0cccc8508ff6@github.com>
 
Message-ID: 

On Fri, 4 Apr 2025 18:17:14 GMT, Timofei Pushkin  wrote:

>> src/java.base/share/classes/jdk/internal/misc/CDS.java line 420:
>> 
>>> 418:                 // class loader. Thus it is safe to delegate their loading to system class loader
>>> 419:                 // (our parent) - this is what the default implementation of loadClass() will do.
>>> 420:                 return (Class) DEFINE_CLASS.invoke(this, name, res);
>> 
>> Instead of subclassing from `URLClassLoader` and go through the trouble of calling its `defineClass()` method, maybe we should just subclass from `ClassLoader` and maintain a hashtable of java.util.jar.JarFiles.
>> 
>> 
>> HashMap map = ....;
>> JarFile jar = map.get(source) ... or open a new JarFile if not found
>> byte[] buffer = read jar file for the given class name;
>> call ClassLoader.defineClass(buffer, ...)
>
> All the opening and reading is handled by `URLClassPath` (it's not just JARs, can also be directories). I used only `defineClass` from `URLClassLoader` to minimize the behavior difference with the old code ? besides defining the class it defines its package and protection domain. But it looks like static CDS strips these anyway, so I've removed `URLClassLoader` entirely.
> 
> `URLClassPath` usage can also be removed ? then the small addition to it from this PR won't be needed but its functionality will be somewhat duplicated in `CDS.UnregisteredLoader`. I've implemented this [in a separate branch](https://github.com/openjdk/jdk/compare/master...TimPushkin:jdk:one-loader-v2?expand=1).

I prefer the changes in your separate branch. URLClassPath is intended for sequential access. Adding the new method for random access could introduce extraneous requirements that might affect future evolution of URLClassPath. As the code for JarSource and Dir Source is quite small, I think it's acceptable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2029438393

From iklam at openjdk.org  Fri Apr  4 21:17:54 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 4 Apr 2025 21:17:54 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v3]
In-Reply-To: 
References: 
 <4h_JVYUvsLEwiafAxd4sSY6DsjlCZIHq_bE03wK4nuw=.707f5fc0-6b63-428d-9c21-0cccc8508ff6@github.com>
 
Message-ID: 

On Fri, 4 Apr 2025 18:13:24 GMT, Timofei Pushkin  wrote:

>> src/java.base/share/classes/jdk/internal/misc/CDS.java line 446:
>> 
>>> 444:         protected Class findClass(String name) throws ClassNotFoundException {
>>> 445:             // Unregistered classes should be found in load(...), registered classes should be
>>> 446:             // handeled by parent loaders
>> 
>> This does seem like a good simplification, as we no longer need to check the `currentClassName`, `currentSuperClass`, etc. 
>> 
>> We had a plan for supported multiple classes for the same name, but we never go around doing it (even though the classlist format supports that with the use of IDs).
>> 
>> I am not sure if the current tests includes a case where a class name `Foo` exists both in the classpath as well as in a custom loader. If not, I think we should add such a case (to ensure that UnregisteredClassLoader never delegates to the application class loader and finds the wrong `Foo`).
>
> Thank you for the review!
> 
>> We had a plan for supported multiple classes for the same name, but we never go around doing it (even though the classlist format supports that with the use of IDs).
> 
> With this approach having multiple unregistered classes with the same name is not possible (JVM will not allow this for a single class loader) so if you are still planning to support this in the near future it would be better to go with the approach originally suggested in the issue: continue using multiple unregistered class loaders but record class loader ID in class list and create only one archiving class loader per recorded ID. But that would be a larger change since it requires class list format to be changed.
> 
>> I am not sure if the current tests includes a case where a class name Foo exists both in the classpath as well as in a custom loader
> 
> Pre-existing `ClassFromSystemModule` test seems to test the boot classpath case. I've also added a new test for the app classpath case.

We don't have immediate plans for supporting multiple classes of the same name. I suspect any future enhancements would be available only through new "AOT" workflow, where the training information, including the unregistered classes, would be encoded in the binary AOT configuration file. Therefore, these future enhancements will not affect this particular case (loading unregistered classes from the classlist text file).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2029445262

From jlu at openjdk.org  Fri Apr  4 21:29:18 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 4 Apr 2025 21:29:18 GMT
Subject: RFR: 8353713: Improve Currency.getInstance exception handling
Message-ID: 

Please review this PR which improves some Currency `IllegalArgumentException`s by including the input in the message. This could be a currency code, country code, or locale. This change also includes tests to check the messages for an invalid country via the region override as well as an invalid country code within a 3 length currency code.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/24459/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24459&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353713
  Stats: 38 lines in 2 files changed: 13 ins; 0 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/24459.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24459/head:pull/24459

PR: https://git.openjdk.org/jdk/pull/24459

From duke at openjdk.org  Fri Apr  4 21:43:58 2025
From: duke at openjdk.org (duke)
Date: Fri, 4 Apr 2025 21:43:58 GMT
Subject: Withdrawn: JDK-8348030 : Extend Math.min and Math.max to support
 multiple parameters
In-Reply-To: 
References: 
Message-ID: 

On Wed, 15 Jan 2025 14:26:32 GMT, Aviad Zer  wrote:

> This change extends the Math.min function to support multiple parameters, improving its usability and code readability.
> 
> Previously, finding the minimum value among multiple variables required using nested Math.min calls or converting the variables into an array and iterating through it. This enhancement provides a more intuitive and straightforward approach to achieve the same result.
> 
> Benefits:
> 
> Simplifies code by eliminating the need for nested Math.min calls.
> Enhances readability, especially when comparing multiple values.
> Offers consistency with existing Math.min usage patterns.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/23138

From naoto at openjdk.org  Fri Apr  4 22:54:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 4 Apr 2025 22:54:53 GMT
Subject: RFR: 8353713: Improve Currency.getInstance exception handling
In-Reply-To: 
References: 
Message-ID: 

On Fri, 4 Apr 2025 21:25:00 GMT, Justin Lu  wrote:

> Please review this PR which improves some Currency `IllegalArgumentException`s by including the input in the message. This could be a currency code, country code, or locale. This change also includes tests to check the messages for an invalid country via the region override as well as an invalid country code within a 3 length currency code.

Looks good.

test/jdk/java/util/Currency/CurrencyTest.java line 102:

> 100:             IllegalArgumentException ex = assertThrows(IllegalArgumentException.class, () ->
> 101:                     Currency.getInstance(badCode), "getInstance() did not throw IAE");
> 102:             assertEquals("The country code: \"%s\" is not a valid ISO 3166 code"

Since the test is not parameterized, we can simply use ".." inside the expected string literal.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24459#pullrequestreview-2744244252
PR Review Comment: https://git.openjdk.org/jdk/pull/24459#discussion_r2029528590

From jlu at openjdk.org  Fri Apr  4 23:03:23 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 4 Apr 2025 23:03:23 GMT
Subject: RFR: 8353713: Improve Currency.getInstance exception handling [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which improves some Currency `IllegalArgumentException`s by including the input in the message. This could be a currency code, country code, or locale. This change also includes tests to check the messages for an invalid country via the region override as well as an invalid country code within a 3 length currency code.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Naoto's review -> use str literal since not param test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24459/files
  - new: https://git.openjdk.org/jdk/pull/24459/files/e79241d0..dab5091b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24459&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24459&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24459.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24459/head:pull/24459

PR: https://git.openjdk.org/jdk/pull/24459

From smarks at openjdk.org  Fri Apr  4 23:46:58 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 4 Apr 2025 23:46:58 GMT
Subject: RFR: 8351740: Clean up some code around initialization of encoding
 properties
Message-ID: 

Various behavior-preserving code cleanups related to system properties related to character encodings.

-------------

Commit messages:
 - More minor cleanups, reversion of some extra changes.
 - WIP: add some non-null asserts and comments on sprops encoding members
 - A couple small tweaks.
 - Merge branch 'master' into JDK-8351740-encoding-properties-cleanup
 - Move platformProperties() native method declaration back to the bottom
 - 8351740: Clean up some logic around initialization of encoding properties

Changes: https://git.openjdk.org/jdk/pull/24463/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24463&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351740
  Stats: 51 lines in 5 files changed: 19 ins; 8 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/24463.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24463/head:pull/24463

PR: https://git.openjdk.org/jdk/pull/24463

From liach at openjdk.org  Sat Apr  5 00:37:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 5 Apr 2025 00:37:48 GMT
Subject: RFR: 8254622: Hide superclasses from conditionally exported
 packages
In-Reply-To: 
References: 
Message-ID: <3TeN5yxeLsHqA9fv2BBz4ErEn0y8zXfHuct9uvc6cak=.19223c83-732e-4ead-82fb-b5f0bb422e02@github.com>

On Fri, 4 Apr 2025 13:36:19 GMT, Hannes Walln?fer  wrote:

> Please review an enhancement to treat classes and interfaces that are not included and not unconditionally exported as hidden. This means they do not show up in the generated documentation even if they are implemented or extended by a documented type. 
> 
> This change makes the `@hidden` JavaDoc tag unnecessary in two internal base classes that previously used it, `jdk.internal.vm.vector.VectorSupport` and `jdk.internal.event.Event`. The generated documentation is unchanged.
> 
> The change also adds support for the `@hidden` JavaDoc tag in interfaces, which was previously missing, and adds coverage to `TestHiddenTag.java`.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java line 165:

> 163:                     for (TypeMirror type : interfaces) {
> 164:                         TypeElement tDoc = utils.asTypeElement(type);
> 165:                         if (!(utils.isPublic(tDoc) || utils.isLinkable(tDoc)) || utils.isHidden(tDoc)) {

This `(!isPublicOrProtected && !isLinkable) || isHidden` trio appears a few times. The conditions are negated and wrapped in parentheses so it is easily confusing on the web; can we extract this check into a new utils method?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24446#discussion_r2029581822

From swen at openjdk.org  Sat Apr  5 01:19:39 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 5 Apr 2025 01:19:39 GMT
Subject: RFR: 8349176: Speed up Integer/Long.toString via
 Unsafe.allocateUninitializedArray [v2]
In-Reply-To: 
References: 
Message-ID: 

> The byte[] allocated in Integer/Long.toString is fully filled, so we can use Unsafe.allocateUninitializedArray to create byte[] to improve performance.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  use StringConcatHelper.newArray

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23353/files
  - new: https://git.openjdk.org/jdk/pull/23353/files/2a06d12f..82e0c387

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23353&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23353&range=00-01

  Stats: 8 lines in 2 files changed: 0 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23353.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23353/head:pull/23353

PR: https://git.openjdk.org/jdk/pull/23353

From swen at openjdk.org  Sat Apr  5 01:22:52 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 5 Apr 2025 01:22:52 GMT
Subject: RFR: 8349176: Speed up Integer/Long.toString via
 StringConcatHelper::newArray [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 5 Apr 2025 01:19:39 GMT, Shaojin Wen  wrote:

>> The byte[] allocated in Integer/Long.toString is fully filled, so we can use StringConcatHelper::newArray to create byte[] to improve performance.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use StringConcatHelper.newArray

The performance of using StringConcatHelper::newArray is the same as using Unsafe.allocateUninitializedArray directly

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23353#issuecomment-2780111344

From jai.forums2013 at gmail.com  Sat Apr  5 02:17:40 2025
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sat, 5 Apr 2025 07:47:40 +0530
Subject: Add "SHA-384" as a known attribute
In-Reply-To: 
References: 
 <6b6c44dd-65ca-4f77-a204-bd2dd8dcbd61@gmail.com>
 <07cc31e5-98f1-49bd-829c-de625216aa6c@gmail.com>
 
Message-ID: <86939f48-2877-440b-843c-87f13758a0e8@gmail.com>

Thank you for reporting this issue and providing the details. I have 
created https://bugs.openjdk.org/browse/JDK-8353787 to track this. Any 
fixes done related to this issue will be first done against the mainline 
JDK and the project members that manage the update releases 
(https://openjdk.org/projects/jdk-updates/) will then decide if/when 
this change should be backported.

-Jaikiran

On 04/04/25 11:55 pm, Ayman wrote:
> Yes, I started looking into this because of a?memory regression.
> While upgrading our project from Java 17 to Java 21, I noticed an 
> increase in memory consumption. After dumping the heap and analyzing 
> the differences, I found that there are a few thousand instances of 
> the class "java.util.jar.Attributes$Name" which all contain the same 
> string which is "SHA-384-Digest".
> In our case, it was a 2MB increase in a process that uses 35MB 
> normally so that's almost?a 5% increase.
> The issue here is that we are loading multiple jars that each contain 
> a MANIFEST file which contains hundreds of classes and so many times 
> the string "SHA-384-Digest".
>
> It would be nice if the fix could be backported to java 21 since it's 
> the current LTS that's impacted.
>
> On Fri, Apr 4, 2025 at 7:07?PM Jaikiran Pai  
> wrote:
>
>     The caching of some attribute names in the java.util.jar.Attributes
>     class appears to have been introduced in
>     https://bugs.openjdk.org/browse/JDK-6805750 (RFR
>     https://mail.openjdk.org/pipermail/core-libs-dev/2018-April/052697.html).
>
>     Given the precedence, it may be OK to add "SHA-384-Digest" to that
>     set,
>     but I don't know how much (if any) would it help with the
>     performance.
>     Did you happen to notice any performance issues which prompted you to
>     look at this cache?
>
>     -Jaikiran
>
>     On 04/04/25 10:25 pm, Jaikiran Pai wrote:
>     > Since this is about caching values in the java.util.jar.Attributes
>     > class, the discussion is more appropriate in the core-libs-dev
>     mailing
>     > list. I've added it to the "To" now and "Bcc"ed the jdk-dev mailing
>     > list. Please subscribe to core-libs-dev
>     > https://mail.openjdk.org/mailman/listinfo/core-libs-dev if you
>     haven't
>     > already and we can continue the discussion there.
>     >
>     > -Jaikiran
>     >
>     > On 04/04/25 8:54 pm, Ayman wrote:
>     >> Hello,
>     >>
>     >> Starting from JDK 19, SHA-384 is replacing SHA-256 as the default
>     >> digest algorithm in the jarsigner:
>     >> https://bugs.openjdk.org/browse/JDK-8283475
>     >>
>     >> This means that the string "SHA-384" is now written multiples
>     times
>     >> is the MANIFEST files, this has been tackled in the past by adding
>     >> the string "SHA-256" as a KNOWN_NAME that shouldn't be
>     duplicated in
>     >> memory:
>     >>
>     https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/jar/Attributes.java#L729
>
>     >>
>     >>
>     >> Is it possible to do the same with "SHA-384"?
>     >>
>     >> Thanks,
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vlivanov at openjdk.org  Sat Apr  5 02:42:38 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Sat, 5 Apr 2025 02:42:38 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
Message-ID: 

Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.

Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.

The patch consists of the following parts:
  * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
  * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
  * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.

`java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.

Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 

Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).

Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)

Thanks!

-------------

Commit messages:
 - Misc fixes and cleanups
 - CPU features support
 - Cleanup
 - TODO list
 - SVML fixes
 - Update templates
 - fixes
 - SLEEF improvements
 - cleanup
 - VectorMathLib: Migrate to lambdas
 - ... and 3 more: https://git.openjdk.org/jdk/compare/9fcb06f9...fc27aee5

Changes: https://git.openjdk.org/jdk/pull/24462/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353786
  Stats: 1274 lines in 43 files changed: 825 ins; 393 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/24462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24462/head:pull/24462

PR: https://git.openjdk.org/jdk/pull/24462

From liach at openjdk.org  Sat Apr  5 02:42:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 5 Apr 2025 02:42:38 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
In-Reply-To: 
References: 
Message-ID: 

On Fri, 4 Apr 2025 22:52:24 GMT, Vladimir Ivanov  wrote:

> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
> 
> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
> 
> The patch consists of the following parts:
>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
> 
> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
> 
> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
> 
> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
> 
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
> 
> Thanks!

Moving vector API library selection to Java code looks like a right step to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24462#issuecomment-2779896358

From clanger at openjdk.org  Sat Apr  5 04:51:52 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Sat, 5 Apr 2025 04:51:52 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 4 Apr 2025 15:22:10 GMT, Severin Gehwolf  wrote:

>> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
>> 
>> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
>> 
>> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
>> 2. For those files the hash sum checks are skipped.
>> 
>> **Testing**
>> 
>> - [x] GHA
>> - [x] `jdk/tools/jlink` jtreg tests
>> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
>> 
>> Thoughts?
>
> Severin Gehwolf 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:
> 
>  - Reboot upgradeable files approach
>  - Revert "8353185: Introduce the concept of upgradeable files in context of JEP 493"
>    
>    This reverts commit bfbfbcb8212ed0f9825549b02b4b52e930c379a7.
>  - Merge branch 'master' into jdk-8353185-upgradable-files-jep493
>  - 8353185: Introduce the concept of upgradeable files in context of JEP 493

Just a few fly-by findings, no full review.

I see that you're actively on the upgradeable files. What about #24190? (@AlanBateman, what are your thoughts, how could we progress there?)

make/modules/jdk.jlink/Java.gmk line 29:

> 27: 
> 28: COPY += \
> 29:   $(TOPDIR)/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/upgrade_files_java.base

Wouldn't `COPY += upgrade_files_java.base` work here ?

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 250:

> 248: 
> 249:     /**
> 250:      * Certain files in the a module are considered upgradeable. That is,

Suggestion:

     * Certain files in a module are considered upgradeable. That is,

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 254:

> 252:      *
> 253:      * @param resPath The resource path of the file to check for upgradeability.
> 254:      * @return {@code true} iff the file is upgradeable. {@code false} otherwise.

Suggestion:

     * @return {@code true} if the file is upgradeable. {@code false} otherwise.

test/jdk/tools/jlink/runtimeImage/UpgradeableFileCacertsTest.java line 43:

> 41:  * @test
> 42:  * @summary Verify warnings are being produced when linking from the run-time
> 43:  *          image and files have been modified

I guess this summary has to be modified.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24388#pullrequestreview-2744611775
PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2029696671
PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2029696836
PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2029696899
PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2029697243

From swen at openjdk.org  Sat Apr  5 05:30:25 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 5 Apr 2025 05:30:25 GMT
Subject: RFR: 8353741: Improve UUID.toString performance by using SIMD
 within a register instead of table lookup [v3]
In-Reply-To: 
References: 
Message-ID: 

> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD within a register) instead of table lookup. Eliminating the table lookup can also avoid the performance degradation problem when the cache misses.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  simplify code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22928/files
  - new: https://git.openjdk.org/jdk/pull/22928/files/93d283e4..55223571

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22928&range=01-02

  Stats: 13 lines in 1 file changed: 0 ins; 4 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/22928.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22928/head:pull/22928

PR: https://git.openjdk.org/jdk/pull/22928

From duke at openjdk.org  Sat Apr  5 14:30:58 2025
From: duke at openjdk.org (Zihao Lin)
Date: Sat, 5 Apr 2025 14:30:58 GMT
Subject: RFR: 8350462: MethodTypeForm.LF_INTERPRET can cache the MemberName
 instead
Message-ID: 

Modify the cache in MethodTypeForm that currently stores the LF_INTERPRET Lambda form. Instead of caching the entire LambdaForm, change it to store a SoftReference. This will avoid unnecessary memory usage.

-------------

Commit messages:
 - Merge branch 'openjdk:master' into JDK-8350462
 - 8350462: MethodTypeForm.LF_INTERPRET can cache the MemberName instead

Changes: https://git.openjdk.org/jdk/pull/24468/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24468&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350462
  Stats: 31 lines in 2 files changed: 17 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24468.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24468/head:pull/24468

PR: https://git.openjdk.org/jdk/pull/24468

From duke at openjdk.org  Sat Apr  5 17:41:00 2025
From: duke at openjdk.org (Markus KARG)
Date: Sat, 5 Apr 2025 17:41:00 GMT
Subject: RFR: 8353795: Add Writer.of(StringBuilder)
Message-ID: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com>

This Pull Requests proposes an implementation for [JDK-8353795](https://bugs.openjdk.org/browse/JDK-8353795): Adding the new method `public static Writer Writer.of(StringBuilder)`, providing a non-synchronized Writer implementation optimized for writing into `StringBuilder`.

A basic test is provided to proof that the new `Writer` behaves as expected. For comparison, the same test is also run against `StringWriter`.

-------------

Commit messages:
 - Removed unused import
 - Limited to Writer.of(StringBuilder)
 - Must not change implementation of StringWriter as getBuffer would not reflect current content of internally used Writer
 - Fixed typo
 - Do not wrap Writer, but return it as-is
 - Forward flush() and close() for Flushable and Closeable
 - Draft: Test for Writer.of(Appendable)
 - Writer.of(Appendable)

Changes: https://git.openjdk.org/jdk/pull/24469/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24469&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353795
  Stats: 379 lines in 4 files changed: 376 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24469/head:pull/24469

PR: https://git.openjdk.org/jdk/pull/24469

From aturbanov at openjdk.org  Sat Apr  5 19:40:49 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 5 Apr 2025 19:40:49 GMT
Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed
 with "RuntimeException: MyObject is not found in test output" [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 28 Mar 2025 01:08:42 GMT, Brent Christian  wrote:

>> I propose some cleanups to `FinalizerHistogramTest.java` to hopefully clear up the intermittent failures:
>> 
>> * run with `othervm`: this test blocks the (global) finalizer thread, and also requires the (global) finalizer thread to enter the test's `finalize()` method
>> * The test uses `volatile` ints, but sets them based on their current value, which is not reliable; convert to `AtomicInteger`
>> * use `PhantomReference`s to ensure that at least two `MyObject`s have become unreachable. If one is stuck in `finalize()`, at least one is still waiting to be finalized and should show up in the histogram.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   convert to WeakRefs, use a RefQ, print ForceGC results

test/jdk/java/lang/ref/FinalizerHistogramTest.java line 70:

> 68:             lock.lock();
> 69:             refQForTwo = new RefQForTwo(new MyObject(), new MyObject());
> 70:             for(int i = 2; i < OBJECTS_COUNT; ++i) {

Suggestion:

            for (int i = 2; i < OBJECTS_COUNT; ++i) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24143#discussion_r2029954070

From liach at openjdk.org  Sun Apr  6 00:06:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 6 Apr 2025 00:06:48 GMT
Subject: RFR: 8350462: MethodTypeForm.LF_INTERPRET can cache the MemberName
 instead
In-Reply-To: 
References: 
Message-ID: 

On Sat, 5 Apr 2025 14:26:13 GMT, Zihao Lin  wrote:

> Modify the cache in MethodTypeForm that currently stores the LF_INTERPRET Lambda form. Instead of caching the entire LambdaForm, change it to store a SoftReference. This will avoid unnecessary memory usage.

src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java line 71:

> 69:     // Indexes into lambdaForms:
> 70:     static final int
> 71:             LF_INVVIRTUAL              =  0,  // DMH invokeVirtual

You can remove the LF_INTERPRET constant from this list.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24468#discussion_r2029997791

From duke at openjdk.org  Sun Apr  6 08:09:27 2025
From: duke at openjdk.org (Zihao Lin)
Date: Sun, 6 Apr 2025 08:09:27 GMT
Subject: RFR: 8350462: MethodTypeForm.LF_INTERPRET can cache the MemberName
 instead [v2]
In-Reply-To: 
References: 
Message-ID: 

> Modify the cache in MethodTypeForm that currently stores the LF_INTERPRET Lambda form. Instead of caching the entire LambdaForm, change it to store a SoftReference. This will avoid unnecessary memory usage.

Zihao Lin has updated the pull request incrementally with one additional commit since the last revision:

  remove LF_INTERPRET

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24468/files
  - new: https://git.openjdk.org/jdk/pull/24468/files/e70fb819..3ce154ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24468&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24468&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24468.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24468/head:pull/24468

PR: https://git.openjdk.org/jdk/pull/24468

From duke at openjdk.org  Sun Apr  6 08:09:27 2025
From: duke at openjdk.org (Zihao Lin)
Date: Sun, 6 Apr 2025 08:09:27 GMT
Subject: RFR: 8350462: MethodTypeForm.LF_INTERPRET can cache the MemberName
 instead [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 6 Apr 2025 00:04:19 GMT, Chen Liang  wrote:

>> Zihao Lin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove LF_INTERPRET
>
> src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java line 71:
> 
>> 69:     // Indexes into lambdaForms:
>> 70:     static final int
>> 71:             LF_INVVIRTUAL              =  0,  // DMH invokeVirtual
> 
> You can remove the LF_INTERPRET constant from this list.

OK, removed it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24468#discussion_r2030074519

From markus at headcrashing.eu  Sun Apr  6 09:22:43 2025
From: markus at headcrashing.eu (Markus KARG)
Date: Sun, 6 Apr 2025 11:22:43 +0200
Subject: Request for Enhancement: java.io.Writer.of(Appendable) as an
 efficient alternative to java.io.StringWriter
In-Reply-To: 
References: <3d41a187-87f5-4a99-80c7-ba0593d4dbc1@headcrashing.eu>
 
 
 
 <6ed5af05-6cc8-46ae-8ef4-4dbbc7f410e8@headcrashing.eu>
 <538b0443-bd36-4286-9a5f-cc6c7d161e37@headcrashing.eu>
 <54518836-3ec8-4253-8c6f-0f3670541c9f@oracle.com>
 
 
 <1b7d9c21-bfb1-43d1-945d-5d8597000968@headcrashing.eu>
 
 <89711f31-592d-4a9f-af1e-13484bfed911@headcrashing.eu>
 
Message-ID: <14e455f1-c87d-4231-a9dd-b74108e5d261@headcrashing.eu>

Chen,

thank you for your API documentation proposal.

For me it is easier to have some code at hand to discuss about, so I 
have filed a Jira-Ticket https://bugs.openjdk.org/browse/JDK-8353795 
with accompanying PR https://github.com/openjdk/jdk/pull/24469, and I 
would propose to continue our discussion in that PR's thread. I will 
adapt the PR to stay aligned with the discussion.

Regards
-Markus

Am 24.03.2025 um 04:48 schrieb Chen Liang:
> Indeed, you are right: The Writer is for legacy APIs to consume 
> instead of intended for users to operate on directly. The lack of IOE 
> on those methods have no impact on the users. Even if we bikeshed 
> about try-catching the returned Writer, StringWriter still declares to 
> throw IOE on its close method, so returning it as a concrete type 
> provides little value.
>
> That said, we can probably start drafting the API documentation of 
> this new API Writer.of(StringBuilder):
>
> {@return a character stream that redirects to a specified StringBuilder}
> 

> The {@code write} and {@code append} invocations are redirected to the 
> {@code append} methods with the same parameter types on the specified 
> StringBuilder, except {@code write(int)}, which delegates to {@code 
> append(char)}. The {@code flush} and {@code close} invocations have no 
> effect.
>
> I propose to specify this explicitly as a delegation proxy; we can 
> infer the lack of thread safety from StringBuilder. (If we want, we 
> can add an API note asking to use StringWriter if thread safety is 
> needed). Also, we don't specify the toString behavior on the returned 
> Writer (unlike for StringWriter); I think users should just use the 
> toString on the StringBuilder.
>
> Chen
>
> ------------------------------------------------------------------------
> *From:* core-libs-dev  on behalf of 
> Markus KARG 
> *Sent:* Sunday, March 23, 2025 11:02 AM
> *To:* Chen Liang 
> *Cc:* core-libs-dev 
> *Subject:* Re: Request for Enhancement: java.io.Writer.of(Appendable) 
> as an efficient alternative to java.io.StringWriter
>
> Chen,
>
> limiting param type to StringBuilder (instead of Appendable) really 
> makes things easier (without standing in the way of some future more 
> general of() variant, eventually): We can easily clarify in JavaDocs 
> how things work like (in the sense of "close and flush are no-ops"). I 
> will prepare a PR on that agreement to have some code at hand to 
> discuss in detail.
>
> Restricting result type to StringWriter (instead of Writer) IMHO is 
> *impossible*, due to the existence of StringWriter::getBuffer(): That 
> method returns StringBuffer, which is synchronized (hence spoils the 
> core idea of Writer.of(): being *non*-synchronized), and unfortunately 
> also is final (so we can't get rid of synchronized using inheritance). 
> Did I miss something?
>
> Anyways, I actually think that being *as least specific as possible* 
> regarding the actual result type is a *good* thing, so users do not 
> imply anything, but actually accept the rules we lay out in the 
> JavaDocs. We should not limit our future possibilities to change 
> without good reason.
>
> -Markus
>
>
> Am 23.03.2025 um 10:06 schrieb Chen Liang:
>> Sorry for a late reply.
>> I wonder if we should make the return type 
>> StringWriter,?given?StringWriter does not throw on its Writer methods 
>> and has a convenient toString. (Making its close() not throws IOE is 
>> binary?compatible but possibly not source compatible)
>> I think this StringBuilder-accepting version in general fits most of 
>> the demands, and we can make it emulate StringWriter in a lot of 
>> behaviors and avoid the nasty issues around closing/flushing.
>>
>> On Sat, Mar 15, 2025, 12:58?PM Markus KARG > > wrote:
>>
>>     Chen,
>>
>>     thank you for sharing your opinion!
>>
>>     Thinking about what you wrote about the "trifecta" complexity, I
>>     think
>>     it might be better to restart my idea from scratch:
>>
>>     As explained in my original proposal
>>     (https://mail.openjdk.org/pipermail/core-libs-dev/2024-December/137807.html
>>     ),
>>
>>     the actual driver for my proposal was to provide a StringWriter
>>     alternative which solves two main problems: It shall prevent String
>>     copies, and it shall be non-synchronized.
>>
>>     What comes into mind is: Writer.of(StringBuilder).
>>
>>     While compared to Appendable this signature is much less
>>     flexible, it
>>     also makes less headaches, but solved in fact those 99% of cases
>>     that
>>     triggered this whole idea: It does not create String copies, and
>>     it is
>>     non-synchronized. What this writer would simply, simply would be
>>     routing
>>     all incoming "append" and "write" calls down to the provided
>>     string builder.
>>
>>     Hence, kindly asking for comments on this updated idea: WDYT about
>>     Writer.of(StringBuilder)?
>>
>>     Thanks!
>>
>>     -Markus
>>
>>
>>     Am 10.02.2025 um 01:51 schrieb Chen Liang:
>>     > Hi Mark,
>>     > After thinking about the Appendable-Closeable-Flushable trio
>>     versus
>>     > Writer, I believe that one problem with Writer.of is that it goes
>>     > against interface segregation principle represented by the
>>     trifecta,
>>     > and accidentally leaking the Closeable or Flushable
>>     functionality is
>>     > still dubious to me. This appears simple, but it may cause
>>     unintended
>>     > consequences, such as if Appendable b implements Closeable too,
>>     its
>>     > closing behavior is not proxied and users may find this
>>     inconsistency
>>     > weird. And as for interface segregation principle, it means APIs
>>     > should request Appendable instead of Writer if they only need
>>     writing
>>     > abilities with no lifecycle; using Writer as the type implies
>>     > potential dependency on closing/flushing behavior, which can
>>     sometimes
>>     > be dangerous.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Sun Apr  6 09:39:47 2025
From: duke at openjdk.org (Markus KARG)
Date: Sun, 6 Apr 2025 09:39:47 GMT
Subject: RFR: 8353795: Add Writer.of(StringBuilder)
In-Reply-To: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com>
References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com>
Message-ID: 

On Sat, 5 Apr 2025 17:36:29 GMT, Markus KARG  wrote:

> This Pull Requests proposes an implementation for [JDK-8353795](https://bugs.openjdk.org/browse/JDK-8353795): Adding the new method `public static Writer Writer.of(StringBuilder)`, providing a non-synchronized Writer implementation optimized for writing into `StringBuilder`.
> 
> A basic test is provided to proof that the new `Writer` behaves as expected. For comparison, the same test is also run against `StringWriter`.

Continuing from thread "[Request for Enhancement: java.io.Writer.of(Appendable) as an efficient alternative to java.io.StringWriter](https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141539.html)":

@liach wrote:
>...we can probably start drafting the API documentation of this new API `Writer.of(StringBuilder)`:
>```java
>@return a character stream that redirects to a specified StringBuilder}
>

>The {@code write} and {@code append} invocations are redirected to the {@code append} methods with the same parameter t>ypes on the specified StringBuilder, except {@code write(int)}, which delegates to {@code append(char)}. The {@code flush} and >{@code close} invocations have no effect.
>```
>I propose to specify this explicitly as a delegation proxy; we can infer the lack of thread safety from `StringBuilder`. (If we want, we can add an API note asking to use `StringWriter` if thread safety is needed). Also, we don't specify the `toString` behavior on the returned Writer (unlike for `StringWriter`); I think users should just use the `toString` on the `StringBuilder`.

Actually I do not see the benefit of documenting which method redirects to what other method or class, but I see that it binds us in future to today's decisions. Also I do not see what benefit notes about `StringWriter` and `toString` would be good for, as leaving it open provides most future flexibility to change eventually (just as we leave open `hashCode` and `equals`).

Having said that, instead I started the PR with a typical JavaDoc as it looks like what we did in `Reader.of()` recently.

WDYT?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2781332523

From duke at openjdk.org  Sun Apr  6 10:54:07 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Sun, 6 Apr 2025 10:54:07 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v57]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
Message-ID: 

On Wed, 31 Jan 2024 10:03:23 GMT, Aggelos Biboudis  wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits:
> 
>  - Merge branch 'master' into primitive-patterns
>  - Update summary in ExactnessConversionsSupportTest
>  - Address review by Jan
>  - Remove redundant null check  and introduce a const boolean for unconditionally exact pairs
>  - Small fix in Javadoc
>  - Tidy up Javadoc of Lower.visitTypeTest
>  - Tidy up Javadoc of IllegalArgumentException in typeSwitch
>  - Improve readability in SwitchBootstraps
>  - Update year
>  - Cleanup redundant clone
>  - ... and 68 more: https://git.openjdk.org/jdk/compare/ec56c72b...f68748b1

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 676:

> 674:         }
> 675:         else if (selectorType.equals(targetType) ||
> 676:                 ((selectorType.equals(byte.class) && !targetType.equals(char.class)) ||

Suggestion:

                ((selectorType.equals(byte.class) && targetType.isPrimitve() && !targetType.equals(boolean.class) && !targetType.equals(char.class)) ||

Otherwise, `SwitchBootstraps.typeSwitch` produces wrong results for `byte`:

var l = MethodHandles.lookup();
var shortType = MethodType.methodType(int.class, short.class, int.class);
var byteType = MethodType.methodType(int.class, byte.class, int.class);

CallSite shortSwitch = SwitchBootstraps.typeSwitch(l, "", shortType, String.class);
CallSite byteSwitch = SwitchBootstraps.typeSwitch(l, "", byteType, String.class);

int shortIndex = (int) shortSwitch.getTarget().invokeExact((short) 1, 0);
int byteIndex = (int) byteSwitch.getTarget().invokeExact((byte) 1, 0);

System.out.println(shortIndex == 1); // true
System.out.println(byteIndex == 1); // false
System.out.println(byteIndex); // 0

This would cause this code to misbehave (if it would compile, which it doesn't):

byte b = 1;
switch (b) {
    case String s -> System.out.println("How did we get here? byte is " + s.getClass());
}

So it isn't really a problem with `javac` but could cause problems for other users of `SwitchBootstraps`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r2030113548

From vklang at openjdk.org  Sun Apr  6 18:19:06 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Sun, 6 Apr 2025 18:19:06 GMT
Subject: RFR: 8353659: SubmissionPublisherTest::testCap1Submit times out
Message-ID: 

This PR reverts the deactivation changes of the updates to FJP introduced in JDK-8319447.

-------------

Commit messages:
 - Addresses deactivation races introduced by JDK-8319447

Changes: https://git.openjdk.org/jdk/pull/24473/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24473&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353659
  Stats: 13 lines in 2 files changed: 2 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24473.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24473/head:pull/24473

PR: https://git.openjdk.org/jdk/pull/24473

From vklang at openjdk.org  Sun Apr  6 18:19:06 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Sun, 6 Apr 2025 18:19:06 GMT
Subject: RFR: 8353659: SubmissionPublisherTest::testCap1Submit times out
In-Reply-To: 
References: 
Message-ID: 

On Sun, 6 Apr 2025 12:36:43 GMT, Viktor Klang  wrote:

> This PR reverts the deactivation changes of the updates to FJP introduced in JDK-8319447.

@AlanBateman @DougLea This is a draft PR for now. I need to run some additional tier-testing in order to promote to a "real" PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24473#issuecomment-2781402414

From vklang at openjdk.org  Mon Apr  7 06:31:49 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 7 Apr 2025 06:31:49 GMT
Subject: RFR: 8353659: SubmissionPublisherTest::testCap1Submit times out
In-Reply-To: 
References: 
Message-ID: <6yATmZ6iLZD4msCS14orNs-oue0dRuFXv8dm9VCAiIs=.507e4df0-1695-400a-b1c0-bd47baf7a96c@github.com>

On Sun, 6 Apr 2025 12:36:43 GMT, Viktor Klang  wrote:

> This PR reverts the deactivation changes of the updates to FJP introduced in JDK-8319447.

@AlanBateman @DougLea Testing-wise this is ready for review and, hopefully, integration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24473#issuecomment-2782159525

From jpai at openjdk.org  Mon Apr  7 06:38:14 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Apr 2025 06:38:14 GMT
Subject: RFR: 8353787: Increased number of SHA-384-Digest
 java.util.jar.Attributes instances leading to higher memory footprint
Message-ID: 

Can I please get a review of this change which proposes to address the increase in memory footprint of an application that uses signed JAR files, signed with `SHA-384` digest algorithm? This addresses https://bugs.openjdk.org/browse/JDK-8353787.

As noted in that issue and the linked mailing list discussion, it has been noticed that when JARs signed with `SHA-384` digest algorithm (which is the default since Java 19) are loaded, the number of `java.util.Attributes$Name` instances held in memory increase, leading to an increase in the memory footprint of the application.

The `Attributes` class has an internal cache which is meant to store `Name` instances of some well-known manifest attributes. It already has the `Name` instances for `SHA1-Digest` and `SHA-256-Digest` manifest attributes cached, but is missing an entry for `SHA-384-Digest`. The commit in this PR adds `SHA-384-Digest` to that cache.

Given the nature of this change, no new jtreg test has been introduced and existing tests in tier1, tier2 and tier3 continue to pass with this change. I've manually verified that this change does reduce the memory footprint of an application which has signed JARs with `SHA-384` digest algorithm  (details in a comment of this PR).

-------------

Commit messages:
 - 8353787: Increased number of SHA-384-Digest java.util.jar.Attributes instances leading to higher memory footprint

Changes: https://git.openjdk.org/jdk/pull/24475/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24475&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353787
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24475.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24475/head:pull/24475

PR: https://git.openjdk.org/jdk/pull/24475

From jpai at openjdk.org  Mon Apr  7 06:42:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Apr 2025 06:42:53 GMT
Subject: RFR: 8353787: Increased number of SHA-384-Digest
 java.util.jar.Attributes$Name instances leading to higher memory footprint
In-Reply-To: 
References: 
Message-ID: 

On Mon, 7 Apr 2025 06:34:11 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this change which proposes to address the increase in memory footprint of an application that uses signed JAR files, signed with `SHA-384` digest algorithm? This addresses https://bugs.openjdk.org/browse/JDK-8353787.
> 
> As noted in that issue and the linked mailing list discussion, it has been noticed that when JARs signed with `SHA-384` digest algorithm (which is the default since Java 19) are loaded, the number of `java.util.Attributes$Name` instances held in memory increase, leading to an increase in the memory footprint of the application.
> 
> The `Attributes` class has an internal cache which is meant to store `Name` instances of some well-known manifest attributes. It already has the `Name` instances for `SHA1-Digest` and `SHA-256-Digest` manifest attributes cached, but is missing an entry for `SHA-384-Digest`. The commit in this PR adds `SHA-384-Digest` to that cache.
> 
> Given the nature of this change, no new jtreg test has been introduced and existing tests in tier1, tier2 and tier3 continue to pass with this change. I've manually verified that this change does reduce the memory footprint of an application which has signed JARs with `SHA-384` digest algorithm  (details in a comment of this PR).

Here's a trivial application which creates and uses signed JARs for use in a `URLClassLoader`. Running this application will show that after the change proposed in this PR, the number of `java.util.jar.Attributes$Name` instances reduce drastically.

Specifically, before this change, the `jmap -histo:live` of this application will show:


 num     #instances         #bytes  class name (module)
-------------------------------------------------------
...
   7:        100127        2403048  java.util.jar.Attributes$Name (java.base at 24)
...

(more than 2MB of `Attributes$Name` instances)

and after this change, the `jmap -histo:live` will show:


 num     #instances         #bytes  class name (module)
-------------------------------------------------------
...
 164:            28            672  java.util.jar.Attributes$Name (java.base at 25-internal)
... 

(just 672 bytes)


import java.util.*;
import java.nio.file.*;
import java.nio.charset.*;
import java.util.jar.*;
import java.net.*;

public class AttributesNameFootprint {

    private static final Path KEYSTORE = // Path.of();
    private static final String ALIAS = // alias in the keystore
    private static final String PASSPHRASE = // passphrase of the keystore

    public static void main(final String[] args) throws Exception {
        // the number of JARs that we want to be used by the application
        // in its classpath
        final int numJARs = 100;
        final List classpath = new ArrayList<>();
        // create some signed JARs
        for (int i = 1; i <= numJARs; i++) {
            final String jarNamePrefix = "jar" + i;
            final Path jar = createJAR(jarNamePrefix, jarNamePrefix + "-entry");
            final Path signed = signJAR(jar);
            classpath.add(signed.toUri().toURL());
        }
        // use those signed JARs in the classpath of a URLClassLoader
        // and load some resources, to trigger the instantiation of the
        // Manifest instances of these JAR files
        try (final URLClassLoader cl = new URLClassLoader(classpath.toArray(URL[]::new))) {
            for (int i = 1; i <= numJARs; i++) {
                final String jarNamePrefix = "jar" + i;
                final String resName = jarNamePrefix + "-entry";
                final URL resource = cl.getResource(resName);
                if (resource == null) {
                    throw new RuntimeException("Failed to find " + resName);
                }
                //System.out.println("found " + resName + " - " + resource);
            }
            // check the memory footprint of the application, especially
            // the number of java.util.jar.Attributes$Name instances
            final long pid = ProcessHandle.current().pid();
            System.out.println("You can now run "jmap -histo:live " + pid + "". Once done, press any key to exit");
            System.in.read();
        }
        System.out.println("done");
    }

    private static Path createJAR(final String jarNamePrefix, final String entryName) throws Exception {
        final Path jarDir = Files.createDirectories(Path.of(".").resolve("jars"));
        final Path jarFile = Files.createTempFile(jarDir, jarNamePrefix, ".jar");

        // create a manifest file which will trigger Manifest instance
        // creation when parsed by the URLClassLoader
        final Manifest manifest = new Manifest();
        final Attributes mainAttrs = manifest.getMainAttributes();
        mainAttrs.putValue("Manifest-Version", "1.0");
        mainAttrs.putValue("Class-Path", "non-existent.jar");
        // create the JAR file with this manifest
        try (final JarOutputStream jaros = new JarOutputStream(Files.newOutputStream(jarFile), manifest)) {
            final JarEntry jarEntry = new JarEntry(entryName);
            jaros.putNextEntry(jarEntry);
            jaros.write(("hello " + entryName).getBytes(StandardCharsets.US_ASCII));
            jaros.closeEntry();
            // create 1000 more entries in the JAR
            for (int i = 0; i < 1000; i++) {
                final String otherEntry = entryName + i;
                final JarEntry other = new JarEntry(otherEntry);
                jaros.putNextEntry(other);
                jaros.write(("hello " + otherEntry).getBytes(StandardCharsets.US_ASCII));
                jaros.closeEntry();
            }
        }
        return jarFile;
    }

    private static Path signJAR(final Path unsignedJAR) throws Exception {
        final Path signedJARDir = Files.createDirectories(Path.of(".").resolve("signed-jars"));
        final Path signedJAR = signedJARDir.resolve("signed-" + unsignedJAR.getFileName());
        final String[] cmd = new String[] {
            "jarsigner",
            "-keystore",
            KEYSTORE.toString(),
            "-storepass",
            PASSPHRASE,
            "-signedjar",
            signedJAR.toString(),
            unsignedJAR.toString(),
            ALIAS

        };
        final ProcessBuilder pb = new ProcessBuilder();
        pb.command(cmd);
        pb.inheritIO();
        final Process p = pb.start();
        final int exitCode = p.waitFor();
        if (exitCode != 0) {
            System.err.println(Arrays.toString(cmd) + " exit code: " + exitCode);
            throw new RuntimeException("failed to sign jar " + unsignedJAR + ", exit code: " + exitCode);
        }
        return signedJAR;
    }
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24475#issuecomment-2782178725

From pminborg at openjdk.org  Mon Apr  7 06:47:11 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 7 Apr 2025 06:47:11 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
In-Reply-To: 
References: 
Message-ID: <9BCE8xN6SA-cPEc1EtuSsqoYwsHiwp31lJKsraWgYso=.67a97434-ef3c-40ab-b5be-841889fdd97c@github.com>

On Fri, 4 Apr 2025 22:52:24 GMT, Vladimir Ivanov  wrote:

> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
> 
> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
> 
> The patch consists of the following parts:
>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
> 
> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
> 
> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
> 
> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
> 
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
> 
> Thanks!

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 258:

> 256:         if (LIBRARY.isSupported(op, vspecies)) {
> 257:             String symbol = LIBRARY.symbolName(op, vspecies);
> 258:             MemorySegment addr = LOOKUP.find(symbol)

It is better to use `LOOKUP.findOrThrow()` because it does not require lambda creation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2030551872

From alanb at openjdk.org  Mon Apr  7 06:48:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 7 Apr 2025 06:48:55 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 4 Apr 2025 19:22:46 GMT, Roger Riggs  wrote:

>> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
>> 
>> @Deprecated(forRemoval = true, since="25")
>> Is added to each class and the existing @apiNote is converted to @deprected
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary SuppressWarnings and correct Deprecated annotation style

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1639:

> 1637:      */
> 1638:     @SuppressWarnings("removal")
> 1639:     static volatile RuntimePermission modifyThreadPermission;

This can be removed, it's not used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2030554666

From jlahoda at openjdk.org  Mon Apr  7 07:01:34 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 7 Apr 2025 07:01:34 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods
Message-ID: 

This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
- `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
- `java. ... .IO` is no longer automatically imported in any compilation unit
- the feature is finalized (i.e. no longer requires `--enable-preview`)

-------------

Commit messages:
 - Moving tests as suggested, removing unused import.
 - Fixing test.
 - Fixing test.
 - Fixing test.
 - Removing unnecessary enable preview from tests.
 - Merge branch 'master' into finalize-concise-source-files
 - Merge remote-tracking branch 'stuart-marks/JavaLangIO' into finalize-concise-source-files
 - Responses to Alan's comments: clean up readln() and align with class spec.
 - Clean up some charset stuff, use stdin.encoding property.
 - Merge branch 'master' into JavaLangIO
 - ... and 16 more: https://git.openjdk.org/jdk/compare/1c2a5533...a5d223e1

Changes: https://git.openjdk.org/jdk/pull/24438/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344706
  Stats: 962 lines in 56 files changed: 294 ins; 585 del; 83 mod
  Patch: https://git.openjdk.org/jdk/pull/24438.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24438/head:pull/24438

PR: https://git.openjdk.org/jdk/pull/24438

From duke at openjdk.org  Mon Apr  7 07:01:34 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Mon, 7 Apr 2025 07:01:34 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods
In-Reply-To: 
References: 
Message-ID: 

On Fri, 4 Apr 2025 07:20:23 GMT, Jan Lahoda  wrote:

> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
> - `java. ... .IO` is no longer automatically imported in any compilation unit
> - the feature is finalized (i.e. no longer requires `--enable-preview`)

src/java.base/share/classes/java/lang/IO.java line 122:

> 120:     public static void print(Object obj) {
> 121:         System.out.print(obj);
> 122:         System.out.flush();

Is it worth using a local variable to avoid calling `print` and `flush` on different streams in case `System.out` is reassigned in between?


var out = System.out;
out.print(obj);
out.flush();

src/java.base/share/classes/java/lang/IO.java line 147:

> 145:         } catch (IOException ioe) {
> 146:             throw new IOError(ioe);
> 147:         }

Was `UncheckedIOException` considered? It might be better for beginners to learn throwing exceptions instead of errors.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2029603325
PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2029604846

From liach at openjdk.org  Mon Apr  7 07:01:34 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Apr 2025 07:01:34 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 5 Apr 2025 00:55:55 GMT, Luca Kellermann  wrote:

>> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
>> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
>> - `java. ... .IO` is no longer automatically imported in any compilation unit
>> - the feature is finalized (i.e. no longer requires `--enable-preview`)
>
> src/java.base/share/classes/java/lang/IO.java line 122:
> 
>> 120:     public static void print(Object obj) {
>> 121:         System.out.print(obj);
>> 122:         System.out.flush();
> 
> Is it worth using a local variable to avoid calling `print` and `flush` on different streams in case `System.out` is reassigned in between?
> 
> 
> var out = System.out;
> out.print(obj);
> out.flush();

This code is not that perf sensitive, guess it is fine as-is

> src/java.base/share/classes/java/lang/IO.java line 147:
> 
>> 145:         } catch (IOException ioe) {
>> 146:             throw new IOError(ioe);
>> 147:         }
> 
> Was `UncheckedIOException` considered? It might be better for beginners to learn throwing exceptions instead of errors.

This implementation is not to be emulated by beginners. If an Exception.is thrown here, a user might be tempted to add handlers in their code, while this is an issue with the setup.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2029660072
PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2029659899

From liach at openjdk.org  Mon Apr  7 07:01:35 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Apr 2025 07:01:35 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods
In-Reply-To: 
References: 
Message-ID: <49kjZQWwnSD9GEJTcXjwNSl6socEa0lOiQCr2M5Mmu8=.6a986db6-5a07-4811-bdc2-2e513c2e2f65@github.com>

On Fri, 4 Apr 2025 07:20:23 GMT, Jan Lahoda  wrote:

> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
> - `java. ... .IO` is no longer automatically imported in any compilation unit
> - the feature is finalized (i.e. no longer requires `--enable-preview`)

src/java.base/share/classes/java/lang/IO.java line 183:

> 181:      * @return the internal BufferedReader instance
> 182:      */
> 183:     static synchronized BufferedReader reader() {

Is the lock only inteneded for initialization, i.e. should it apply for simply getting the reader?

test/jdk/java/io/IO/IO.java line 1:

> 1: /*

Shouldn't the package of this test be moved to java/lang?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2029576244
PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2029576615

From jlahoda at openjdk.org  Mon Apr  7 07:05:00 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 7 Apr 2025 07:05:00 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods
In-Reply-To: <49kjZQWwnSD9GEJTcXjwNSl6socEa0lOiQCr2M5Mmu8=.6a986db6-5a07-4811-bdc2-2e513c2e2f65@github.com>
References: 
 <49kjZQWwnSD9GEJTcXjwNSl6socEa0lOiQCr2M5Mmu8=.6a986db6-5a07-4811-bdc2-2e513c2e2f65@github.com>
Message-ID: 

On Sat, 5 Apr 2025 00:20:29 GMT, Chen Liang  wrote:

>> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
>> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
>> - `java. ... .IO` is no longer automatically imported in any compilation unit
>> - the feature is finalized (i.e. no longer requires `--enable-preview`)
>
> src/java.base/share/classes/java/lang/IO.java line 183:
> 
>> 181:      * @return the internal BufferedReader instance
>> 182:      */
>> 183:     static synchronized BufferedReader reader() {
> 
> Is the lock only inteneded for initialization, i.e. should it apply for simply getting the reader?

I believe there needs to be some barriers (at least `volatile`) even for getting the already initialized reader. And then, given the code here, it is probably fine and less error prone to simply use `synchronized` that something more complex.

But, given we'll hopefully have `@StableValue` soon, maybe we could use that? What do you think @stuart-marks?

Thanks!

> test/jdk/java/io/IO/IO.java line 1:
> 
>> 1: /*
> 
> Shouldn't the package of this test be moved to java/lang?

Done:
https://github.com/openjdk/jdk/pull/24438/commits/a5d223e14cadeb0e331d66d9030b780651f0cd64
Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2030575903
PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2030576686

From cstein at openjdk.org  Mon Apr  7 07:19:54 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 7 Apr 2025 07:19:54 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods
In-Reply-To: 
References: 
Message-ID: 

On Fri, 4 Apr 2025 07:20:23 GMT, Jan Lahoda  wrote:

> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
> - `java. ... .IO` is no longer automatically imported in any compilation unit
> - the feature is finalized (i.e. no longer requires `--enable-preview`)

Changes in source launcher related tests look good.

-------------

Marked as reviewed by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24438#pullrequestreview-2745745703

From tpushkin at openjdk.org  Mon Apr  7 07:46:52 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 7 Apr 2025 07:46:52 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v4]
In-Reply-To: 
References: 
Message-ID: <_jUyfQOHTQHeuKp72nHVOjSJJZtmjx-6ViBd9qi-IpA=.06a4213b-7834-4eda-b50f-4d362bbb761c@github.com>

> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app.
> 
> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible.
> 
> Implementation note: `URLClassLoader` does not allow selecting a specific URL to load a specific class ? I used reflection to override a private part of `URLClassLoader` responsible for URL selection while being able to use the rest of its implementation.

Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:

  Don't use URLClassPath

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24223/files
  - new: https://git.openjdk.org/jdk/pull/24223/files/5db07cef..16a2f951

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=02-03

  Stats: 150 lines in 4 files changed: 62 ins; 67 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/24223.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223

PR: https://git.openjdk.org/jdk/pull/24223

From pminborg at openjdk.org  Mon Apr  7 08:33:41 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 7 Apr 2025 08:33:41 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v42]
In-Reply-To: 
References: 
Message-ID: <6IEFhHquQQ3MQQPENwRQdr7Jix57APZobEGhNED9UVg=.4964492c-eec5-4ecd-8afd-0ec087ff5fd7@github.com>

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 295 commits:

 - Update doces
 - Merge branch 'master' into implement-jep502
 - Merge branch 'master' into implement-jep502
 - Address comments on docs
 - Make the sqrt example different
 - Specify that an exception is thrown for illegal inputs
 - Clean up StableValue docs
 - Break out and move performance related text
 - Move Serializable specs to @implNote
 - Address comments
 - ... and 285 more: https://git.openjdk.org/jdk/compare/d1e91fcd...f1d96441

-------------

Changes: https://git.openjdk.org/jdk/pull/23972/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=41
  Stats: 4558 lines in 30 files changed: 4536 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From pminborg at openjdk.org  Mon Apr  7 08:39:58 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 7 Apr 2025 08:39:58 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v43]
In-Reply-To: 
References: 
Message-ID: <0ioJvwMxrWnNsg331b79T5FI-OojlKTYG7ZkY63ffZg=.5406cc1f-ab73-4039-84ac-99929654e53d@github.com>

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix doc issue with NULL_SENTINEL

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/f1d96441..365d9468

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=42
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=41-42

  Stats: 8 lines in 1 file changed: 4 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From pminborg at openjdk.org  Mon Apr  7 08:45:50 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 7 Apr 2025 08:45:50 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v44]
In-Reply-To: 
References: 
Message-ID: <4j9m3QEq1w0sSBwKVPHEvoq4IZbRbiRovIPqgefYlEk=.a1df3fb5-fbfc-44ad-abec-058a3af7222e@github.com>

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add comment about stable fun/coll and fix typos

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/365d9468..0f11342f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=43
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=42-43

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From sgehwolf at openjdk.org  Mon Apr  7 08:54:52 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 7 Apr 2025 08:54:52 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sat, 5 Apr 2025 04:49:03 GMT, Christoph Langer  wrote:

> I see that you're actively on the upgradeable files. What about #24190?

Let's keep the discussion on #24190, please.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2782507174

From sgehwolf at openjdk.org  Mon Apr  7 09:03:51 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 7 Apr 2025 09:03:51 GMT
Subject: RFR: 8352689: Allow for hash sum overrides when linking from the
 run-time image [v2]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
Message-ID: 

On Tue, 1 Apr 2025 16:12:39 GMT, Alan Bateman  wrote:

> > @AlanBateman Any more thoughts on this? We'd need to include a patch like this one for getting the Fedora JDK 24+ builds to work with JEP 493 enabled. Thanks!
> 
> Allowing for a small number of upgradable files is needed, I see you have a JBS issue for that. I have not warmed to the proposal to have override or have alt hashes, I think we need to think spend more time thinking about the issues there.

Another way to solve the `*.pdb` issue on Windows would be to keep the `JMODs` view of the world (which have stripped or minimal pdb files with naming `.pdb`) consistent in the JDK image if and only if both options `--enable-linkable-runtime` and `--with-external-symbols-in-bundles=public` are **both** on. That is the full PDB files could be in the JDK image as `.full.pdb` if needed. Or alternatively copied over by means of installing the debug bundle over it when debugging is needed.

This keeps the RPM case unsolved where a JDK build might have specified `--with-native-debug-symbols=internal` and some RPM post-build processing strips the debug symbols from the binary and places the symbols in an extra package.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24190#issuecomment-2782532442

From jpai at openjdk.org  Mon Apr  7 09:05:36 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Apr 2025 09:05:36 GMT
Subject: RFR: 8066583: DeflaterInput/OutputStream and
 InflaterInput/OutputStream should explain responsibility for freeing resources
 [v10]
In-Reply-To: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com>
References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com>
Message-ID: 

> Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`.
> 
> The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes.
> 
> I'll draft a CSR once we agree on the proposed text.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  "a" instead of "the"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23655/files
  - new: https://git.openjdk.org/jdk/pull/23655/files/ae42a9e3..82ff8d73

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23655&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23655&range=08-09

  Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23655/head:pull/23655

PR: https://git.openjdk.org/jdk/pull/23655

From alanb at openjdk.org  Mon Apr  7 09:05:36 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 7 Apr 2025 09:05:36 GMT
Subject: RFR: 8066583: DeflaterInput/OutputStream and
 InflaterInput/OutputStream should explain responsibility for freeing resources
 [v10]
In-Reply-To: 
References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com>
 
Message-ID: 

On Mon, 7 Apr 2025 09:02:04 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`.
>> 
>> The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes.
>> 
>> I'll draft a CSR once we agree on the proposed text.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   "a" instead of "the"

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23655#pullrequestreview-2746054802

From alanb at openjdk.org  Mon Apr  7 09:14:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 7 Apr 2025 09:14:52 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods
In-Reply-To: 
References: 
Message-ID: 

On Fri, 4 Apr 2025 07:20:23 GMT, Jan Lahoda  wrote:

> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
> - `java. ... .IO` is no longer automatically imported in any compilation unit
> - the feature is finalized (i.e. no longer requires `--enable-preview`)

src/java.base/share/classes/java/lang/IO.java line 45:

> 43:  * UTF-8 is used instead. These internal objects are created upon the first call to
> 44:  * either of the {@code readln} methods and are stored for subsequent reuse by these
> 45:  * methods.

@stuart-marks Can we rephrase this paragraph so that it doesn't use phrase "internal objects"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2030812095

From alanb at openjdk.org  Mon Apr  7 09:20:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 7 Apr 2025 09:20:59 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sat, 5 Apr 2025 02:30:33 GMT, Chen Liang  wrote:

>> src/java.base/share/classes/java/lang/IO.java line 147:
>> 
>>> 145:         } catch (IOException ioe) {
>>> 146:             throw new IOError(ioe);
>>> 147:         }
>> 
>> Was `UncheckedIOException` considered? It might be better for beginners to learn throwing exceptions instead of errors.
>
> This implementation is not to be emulated by beginners. If an Exception.is thrown here, a user might be tempted to add handlers in their code, while this is an issue with the setup.

Someone is bound to ask why the readln method throw but the println methods don't.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2030830662

From pminborg at openjdk.org  Mon Apr  7 09:34:37 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 7 Apr 2025 09:34:37 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v45]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add note an partial and total functions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/0f11342f..5003dce1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=44
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=43-44

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From mcimadamore at openjdk.org  Mon Apr  7 09:49:03 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Apr 2025 09:49:03 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Thu, 3 Apr 2025 14:26:15 GMT, Quan Anh Mai  wrote:

>> I don't think we should promise this even though it might be the case.
>
> What is the benefit of not promising it? Promising helps the supplier to have a well-defined order of execution. Furthermore, even if you do not promise it, it is the only possible implementation now and people will depend on it regardless.

I tend to agree with @merykitty - what that guarantee says is that - e.g. you can't have an exceptional call to the supplier (but this holds also for `orElseSet`) _after_ the stable value has been set. I think we already guarantee this implicitly, because we say that the action in `orElseSet` is never executed if the stable value has been set -- which implies that at least a supplier terminated normally (and that must be the last one -- otherwise it would not have executed at all...)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2030878861

From pminborg at openjdk.org  Mon Apr  7 09:55:53 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 7 Apr 2025 09:55:53 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v46]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/5003dce1..26b84e89

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=45
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=44-45

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From pminborg at openjdk.org  Mon Apr  7 09:55:55 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 7 Apr 2025 09:55:55 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v45]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 7 Apr 2025 09:34:37 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add note an partial and total functions

Here are the latest generated docs for `StableValue`: https://cr.openjdk.org/~pminborg/stable-values2/api/java.base/java/lang/StableValue.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2782754483

From jorn.vernee at oracle.com  Mon Apr  7 10:46:55 2025
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Mon, 7 Apr 2025 12:46:55 +0200
Subject: Usage feedback: jnativescan
In-Reply-To: 
References: 
Message-ID: <98b89a42-7ac9-457e-bfbb-6eeb71835add@oracle.com>

Hello,


I had a look here, and can reproduce the error.


jnativescan does have handling for Multi-Release jars. By default it 
uses the current JDK version, which in your case would be 24. An exact 
version can be specified using --release. The issue in this case is that 
the error originates from the class file 
reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException, 
which does not have a class file entry in the META-INF/versions 
directory. There is one for the enclosing class 
reactor.core.publisher.CallSiteSupplierFactory, but not for this nested 
class. jnativescan doesn't try to determine whether a class file is 
used, it just scans all the class files in the jar file that belong to a 
particular runtime version, so in this case, it doesn't see that the 
TracingException class is not actually being used.


I think your idea of emitting a warning instead of an error is probably 
the right one. We won't be able to determine whether a method being 
referenced is restricted or not, since you need the class file to be 
able to look at the annotations, but if the class can not be loaded on 
the particular runtime version, then even if the method was restricted, 
it could never be called any way.


Thank you for submitting this useful piece of feedback! I've filed: 
https://bugs.openjdk.org/browse/JDK-8353840


Jorn


On 4-4-2025 18:58, Danish Nawab wrote:
> |jnativescan|?terminates when ran on a JAR with a missing class.
> Example:
>
> ```
> jnativescan --class-path reactor-core-3.7.4.jar
>
> ERROR: Error while processing method: 
> reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String
> CAUSED BY: System class can not be found: sun.misc.JavaLangAccess
> ```
>
> (above jar downloaded from [1])
>
> The offending class seems to refer to a now unavailable 
> |sun.misc.JavaLangAccess|?but still handles this error scenario 
> silently [2]
>
> Because |jnativescan|?terminates early, I can't say whether or not 
> this library uses native/restricted features. Perhaps it would be 
> better if instead of terminating, |jnativescan|?continued the analysis 
> after warning about the missing class.
>
> Also, the above JAR seems to be a Multi-Release Jar, where the Java 
> 11+ version of the code does not even refer sun.misc.JavaLangAccess [3].
> Should |jnativescan|?have special handling for Multi-Release JARs by 
> analysing the version that would be applicable for the current JDK?
>
> Versions:
> ```
> java --version
> openjdk 24 2025-03-18
> OpenJDK Runtime Environment (build 24+36-3646)
> OpenJDK 64-Bit Server VM (build 24+36-3646, mixed mode, sharing)
>
> jnativescan --version
> 24
> ```
>
> Overall, |jnativescan|?is extremely helpful in finding the 
> dependencies using native/restricted features.
>
> [1] 
> https://repo1.maven.org/maven2/io/projectreactor/reactor-core/3.7.4/reactor-core-3.7.4.jar 
> 
> [2] 
> https://github.com/reactor/reactor-core/blob/7dee739/reactor-core/src/main/java/reactor/core/publisher/CallSiteSupplierFactory.java#L56-L64 
> 
> [3] 
> https://github.com/reactor/reactor-core/blob/0b93178/reactor-core/src/main/java11/reactor/core/publisher/CallSiteSupplierFactory.java 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pminborg at openjdk.org  Mon Apr  7 11:17:36 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 7 Apr 2025 11:17:36 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v47]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Only use partial functions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/26b84e89..7e15e49e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=46
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=45-46

  Stats: 99 lines in 2 files changed: 57 ins; 27 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From tpushkin at openjdk.org  Mon Apr  7 11:39:52 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 7 Apr 2025 11:39:52 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v4]
In-Reply-To: 
References: 
 <4h_JVYUvsLEwiafAxd4sSY6DsjlCZIHq_bE03wK4nuw=.707f5fc0-6b63-428d-9c21-0cccc8508ff6@github.com>
 
 
Message-ID: 

On Fri, 4 Apr 2025 21:11:52 GMT, Ioi Lam  wrote:

>> All the opening and reading is handled by `URLClassPath` (it's not just JARs, can also be directories). I used only `defineClass` from `URLClassLoader` to minimize the behavior difference with the old code ? besides defining the class it defines its package and protection domain. But it looks like static CDS strips these anyway, so I've removed `URLClassLoader` entirely.
>> 
>> `URLClassPath` usage can also be removed ? then the small addition to it from this PR won't be needed but its functionality will be somewhat duplicated in `CDS.UnregisteredLoader`. I've implemented this [in a separate branch](https://github.com/openjdk/jdk/compare/master...TimPushkin:jdk:one-loader-v2?expand=1).
>
> I prefer the changes in your separate branch. URLClassPath is intended for sequential access. Adding the new method for random access could introduce extraneous requirements that might affect future evolution of URLClassPath. As the code for JarSource and Dir Source is quite small, I think it's acceptable.

Agree, I've brought it here

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2031053093

From dl at openjdk.org  Mon Apr  7 11:47:53 2025
From: dl at openjdk.org (Doug Lea)
Date: Mon, 7 Apr 2025 11:47:53 GMT
Subject: RFR: 8353659: SubmissionPublisherTest::testCap1Submit times out
In-Reply-To: 
References: 
Message-ID: 

On Sun, 6 Apr 2025 12:36:43 GMT, Viktor Klang  wrote:

> This PR reverts the deactivation changes of the updates to FJP introduced in JDK-8319447.

Looks good. Thanks for tracking this down.

-------------

Marked as reviewed by dl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24473#pullrequestreview-2746525468

From sgehwolf at openjdk.org  Mon Apr  7 12:11:51 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 7 Apr 2025 12:11:51 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v3]
In-Reply-To: 
References: 
Message-ID: 

> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
> 
> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
> 
> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
> 2. For those files the hash sum checks are skipped.
> 
> **Testing**
> 
> - [x] GHA
> - [x] `jdk/tools/jlink` jtreg tests
> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
> 
> Thoughts?

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Review comments from Christoph

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24388/files
  - new: https://git.openjdk.org/jdk/pull/24388/files/74b6bfe1..fe33cfd7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24388&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24388&range=01-02

  Stats: 7 lines in 4 files changed: 0 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24388/head:pull/24388

PR: https://git.openjdk.org/jdk/pull/24388

From sgehwolf at openjdk.org  Mon Apr  7 12:11:55 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 7 Apr 2025 12:11:55 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sat, 5 Apr 2025 04:45:00 GMT, Christoph Langer  wrote:

>> Severin Gehwolf 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:
>> 
>>  - Reboot upgradeable files approach
>>  - Revert "8353185: Introduce the concept of upgradeable files in context of JEP 493"
>>    
>>    This reverts commit bfbfbcb8212ed0f9825549b02b4b52e930c379a7.
>>  - Merge branch 'master' into jdk-8353185-upgradable-files-jep493
>>  - 8353185: Introduce the concept of upgradeable files in context of JEP 493
>
> make/modules/jdk.jlink/Java.gmk line 29:
> 
>> 27: 
>> 28: COPY += \
>> 29:   $(TOPDIR)/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/upgrade_files_java.base
> 
> Wouldn't `COPY += upgrade_files_java.base` work here ?

Apparently it does. Thanks for the suggestion.

> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 250:
> 
>> 248: 
>> 249:     /**
>> 250:      * Certain files in the a module are considered upgradeable. That is,
> 
> Suggestion:
> 
>      * Certain files in a module are considered upgradeable. That is,

Fixed.

> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 254:
> 
>> 252:      *
>> 253:      * @param resPath The resource path of the file to check for upgradeability.
>> 254:      * @return {@code true} iff the file is upgradeable. {@code false} otherwise.
> 
> Suggestion:
> 
>      * @return {@code true} if the file is upgradeable. {@code false} otherwise.

Fixed.

> test/jdk/tools/jlink/runtimeImage/UpgradeableFileCacertsTest.java line 43:
> 
>> 41:  * @test
>> 42:  * @summary Verify warnings are being produced when linking from the run-time
>> 43:  *          image and files have been modified
> 
> I guess this summary has to be modified.

Thanks, fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2031103556
PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2031102867
PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2031102616
PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2031102257

From clanger at openjdk.org  Mon Apr  7 12:16:56 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 7 Apr 2025 12:16:56 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 7 Apr 2025 12:11:51 GMT, Severin Gehwolf  wrote:

>> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
>> 
>> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
>> 
>> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
>> 2. For those files the hash sum checks are skipped.
>> 
>> **Testing**
>> 
>> - [x] GHA
>> - [x] `jdk/tools/jlink` jtreg tests
>> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments from Christoph

test/jdk/tools/jlink/runtimeImage/UpgradeableFileCacertsTest.java line 42:

> 40: /*
> 41:  * @test
> 42:  * @summary Verify that no errors are reported for files the have been

Suggestion:

 * @summary Verify that no errors are reported for files that have been

?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2031112907

From clanger at openjdk.org  Mon Apr  7 12:18:56 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 7 Apr 2025 12:18:56 GMT
Subject: RFR: 8352935: Launcher should not add $JDK/../lib to
 LD_LIBRARY_PATH [v3]
In-Reply-To: 
References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
 
Message-ID: 

On Fri, 4 Apr 2025 09:22:10 GMT, Joachim Kern  wrote:

>> In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so.
>> 
>> The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Proposal from RealCLanger to further cleanup test Test7029048

No regressions spotted, even after the test cleanup. LGTM.

-------------

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24351#pullrequestreview-2746610204

From sgehwolf at openjdk.org  Mon Apr  7 12:24:01 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 7 Apr 2025 12:24:01 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 7 Apr 2025 12:14:28 GMT, Christoph Langer  wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments from Christoph
>
> test/jdk/tools/jlink/runtimeImage/UpgradeableFileCacertsTest.java line 42:
> 
>> 40: /*
>> 41:  * @test
>> 42:  * @summary Verify that no errors are reported for files the have been
> 
> Suggestion:
> 
>  * @summary Verify that no errors are reported for files that have been
> 
> ?

Sigh. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2031123405

From pminborg at openjdk.org  Mon Apr  7 12:25:37 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 7 Apr 2025 12:25:37 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v48]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Update examples
 - Remove parantheses

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/7e15e49e..f1f188b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=47
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=46-47

  Stats: 52 lines in 2 files changed: 8 ins; 4 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From pminborg at openjdk.org  Mon Apr  7 12:33:28 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 7 Apr 2025 12:33:28 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v49]
In-Reply-To: 
References: 
Message-ID: <2CJOBB1FcTvxqZP3SmVSbjE8uBUi9JzJowxLAcQO8NA=.f8a7ffa0-1897-4e89-8745-02048ae6d6fc@github.com>

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/f1f188b2..0a0e5203

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=48
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=47-48

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From jengebr at amazon.com  Mon Apr  7 12:35:44 2025
From: jengebr at amazon.com (Engebretson, John)
Date: Mon, 7 Apr 2025 12:35:44 +0000
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: 
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 
 <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 
Message-ID: 

  Thank you Brian, I?m sorry I missed this point!  The hint in this case is the parameter on the overloaded constructor; if set high enough, the initially-allocated buffer will guarantee exactly one array allocation with no growth.  This is identical to the ByteArrayOutputStream behavior described on [1].
  However, both issues focus on the far more common case of not knowing the final payload size, or perhaps making a bad guess; [1] attempts to modify the scale while [2] rewrites the data structure for greater gain.
     John

From: core-libs-dev  On Behalf Of Brian Burkhalter
Sent: Friday, April 4, 2025 3:31 PM
To: core-libs-dev at openjdk.org
Subject: RE: [EXTERNAL] JDK-8352891 Performance improvements to ByteArrayOutputStream


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


I did not notice that Alan?s comment below, about adding a hint as to the maximum expected size, has been specifically addressed anywhere in this discussion. It might not be all that pertinent to the main thread of discussion, however, but it would certainly be useful for the issue [1], which I linked to [2].

Brian

[1] https://bugs.openjdk.org/browse/JDK-8329287
[2] https://bugs.openjdk.org/browse/JDK-8353729


On Apr 2, 2025, at 3:52?AM, Alan Bateman > wrote:

[?] and whether having a parameter to specify the initial size or some hint of the max size would help the discussion.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pminborg at openjdk.org  Mon Apr  7 12:42:54 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 7 Apr 2025 12:42:54 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v50]
In-Reply-To: 
References: 
Message-ID: <0zvnqZbI6I19ErL-S4x4UeOatdONG3bGM84ltmigilE=.8c43f606-b167-4b64-962c-d898fca78c62@github.com>

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Change double to int

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/0a0e5203..111f4d0d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=49
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=48-49

  Stats: 10 lines in 1 file changed: 3 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From mullan at openjdk.org  Mon Apr  7 12:52:50 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 7 Apr 2025 12:52:50 GMT
Subject: RFR: 8353787: Increased number of SHA-384-Digest
 java.util.jar.Attributes$Name instances leading to higher memory footprint
In-Reply-To: 
References: 
Message-ID: <98OAnQYTAmLgk3M-BpSwXxng7pXvzAnMppER1FYcwUk=.76fee1fe-6f9d-4625-8f16-8cf6e398cdfa@github.com>

On Mon, 7 Apr 2025 06:34:11 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this change which proposes to address the increase in memory footprint of an application that uses signed JAR files, signed with `SHA-384` digest algorithm? This addresses https://bugs.openjdk.org/browse/JDK-8353787.
> 
> As noted in that issue and the linked mailing list discussion, it has been noticed that when JARs signed with `SHA-384` digest algorithm (which is the default since Java 19) are loaded, the number of `java.util.Attributes$Name` instances held in memory increase, leading to an increase in the memory footprint of the application.
> 
> The `Attributes` class has an internal cache which is meant to store `Name` instances of some well-known manifest attributes. It already has the `Name` instances for `SHA1-Digest` and `SHA-256-Digest` manifest attributes cached, but is missing an entry for `SHA-384-Digest`. The commit in this PR adds `SHA-384-Digest` to that cache.
> 
> Given the nature of this change, no new jtreg test has been introduced and existing tests in tier1, tier2 and tier3 continue to pass with this change. I've manually verified that this change does reduce the memory footprint of an application which has signed JARs with `SHA-384` digest algorithm  (details in a comment of this PR).

I suggest making this a P3 since it sounds like it would be useful to backport to 21.

-------------

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24475#pullrequestreview-2746704222

From jkern at openjdk.org  Mon Apr  7 12:53:55 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 7 Apr 2025 12:53:55 GMT
Subject: Integrated: 8352935: Launcher should not add $JDK/../lib to
 LD_LIBRARY_PATH
In-Reply-To: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
Message-ID: <99CT0RitnWPbJEJgRb6KLx3J030x1c8CGp7wnX0kxLY=.9065328e-6445-489f-9937-46fbb4c3eff0@github.com>

On Tue, 1 Apr 2025 09:13:45 GMT, Joachim Kern  wrote:

> In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so.
> 
> The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed.

This pull request has now been integrated.

Changeset: 9128ec61
Author:    Joachim Kern 
URL:       https://git.openjdk.org/jdk/commit/9128ec61df430a2eb352f58ec9799d332f7b1a10
Stats:     31 lines in 3 files changed: 2 ins; 20 del; 9 mod

8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH

Reviewed-by: clanger, ihse, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/24351

From jpai at openjdk.org  Mon Apr  7 12:58:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Apr 2025 12:58:50 GMT
Subject: RFR: 8353787: Increased number of SHA-384-Digest
 java.util.jar.Attributes$Name instances leading to higher memory footprint
In-Reply-To: <98OAnQYTAmLgk3M-BpSwXxng7pXvzAnMppER1FYcwUk=.76fee1fe-6f9d-4625-8f16-8cf6e398cdfa@github.com>
References: 
 <98OAnQYTAmLgk3M-BpSwXxng7pXvzAnMppER1FYcwUk=.76fee1fe-6f9d-4625-8f16-8cf6e398cdfa@github.com>
Message-ID: 

On Mon, 7 Apr 2025 12:49:45 GMT, Sean Mullan  wrote:

> I suggest making this a P3 since it sounds like it would be useful to backport to 21.

Done - I've marked it as a P3, and I agree that this is worth backporting.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24475#issuecomment-2783248254

From sgehwolf at openjdk.org  Mon Apr  7 13:35:58 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 7 Apr 2025 13:35:58 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 7 Apr 2025 12:21:06 GMT, Severin Gehwolf  wrote:

>> test/jdk/tools/jlink/runtimeImage/UpgradeableFileCacertsTest.java line 42:
>> 
>>> 40: /*
>>> 41:  * @test
>>> 42:  * @summary Verify that no errors are reported for files the have been
>> 
>> Suggestion:
>> 
>>  * @summary Verify that no errors are reported for files that have been
>> 
>> ?
>
> Sigh. Thanks!

Fixed in https://github.com/openjdk/jdk/pull/24388/commits/89d3886d1803f3dc033423e59325a41c565d7a25

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2031254581

From sgehwolf at openjdk.org  Mon Apr  7 13:35:57 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 7 Apr 2025 13:35:57 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v4]
In-Reply-To: 
References: 
Message-ID: 

> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
> 
> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
> 
> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
> 2. For those files the hash sum checks are skipped.
> 
> **Testing**
> 
> - [x] GHA
> - [x] `jdk/tools/jlink` jtreg tests (also on [GHA](https://github.com/jerboaa/jdk/actions/runs/14308729271))
> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
> 
> Thoughts?

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Review v2

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24388/files
  - new: https://git.openjdk.org/jdk/pull/24388/files/fe33cfd7..89d3886d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24388&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24388&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24388/head:pull/24388

PR: https://git.openjdk.org/jdk/pull/24388

From vklang at openjdk.org  Mon Apr  7 13:55:27 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 7 Apr 2025 13:55:27 GMT
Subject: RFR: 8352971: Increase maximum number of hold counts for
 ReentrantReadWriteLock [v2]
In-Reply-To: 
References: 
Message-ID: 

> I'm breaking this change out as a separate improvement, since it will not be generally possible to adjust these limits on the j.u.c primitives since they might already use a backing `long` to pack in information which needs to be updated atomically (would require 128-bit atomics to widen them, and it still infeasible to change return types of pre-existing APIs).

Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Make sure that the test fails in case of an InterruptedException
 - Adding support for more than 65k readers and writers of ReentrantReadWriteLock

-------------

Changes: https://git.openjdk.org/jdk/pull/24261/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24261&range=01
  Stats: 140 lines in 4 files changed: 105 ins; 0 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/24261.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24261/head:pull/24261

PR: https://git.openjdk.org/jdk/pull/24261

From vklang at openjdk.org  Mon Apr  7 13:55:28 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 7 Apr 2025 13:55:28 GMT
Subject: RFR: 8352971: Increase maximum number of hold counts for
 ReentrantReadWriteLock [v2]
In-Reply-To: <7nuBme2ZUc4sCr4M_fCv2WCwh8-RGfUEbCV25gS4DTQ=.c2b7a8cb-92a8-4672-9ce3-967591ea6fab@github.com>
References: 
 
 <7nuBme2ZUc4sCr4M_fCv2WCwh8-RGfUEbCV25gS4DTQ=.c2b7a8cb-92a8-4672-9ce3-967591ea6fab@github.com>
Message-ID: <6ZkMpuSsVjQMWcNWC0zi0hlWbkXBNjJmfJ6-wTllL74=.16e548c5-4f43-474f-9f0b-d688c41dacee@github.com>

On Wed, 2 Apr 2025 13:09:01 GMT, Viktor Klang  wrote:

>> test/jdk/java/util/concurrent/tck/ReentrantReadWriteLock20Test.java line 94:
>> 
>>> 92:                         next.join();
>>> 93:                     } catch (InterruptedException ie) {
>>> 94:                     }
>> 
>> I don't think we should swallow InterruptedException here. The only reason that the main thread will be interrupted here is if jtreg is trying to timeout the test, so I think it should throw when that happens.
>
> @AlanBateman Yeah, that seems sensible, I'll amend the PR.

Had to force-push since I needed to rebase, but the test should have been amended now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24261#discussion_r2031296854

From alanb at openjdk.org  Mon Apr  7 13:55:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 7 Apr 2025 13:55:51 GMT
Subject: RFR: 8353659: SubmissionPublisherTest::testCap1Submit times out
In-Reply-To: 
References: 
Message-ID: 

On Sun, 6 Apr 2025 12:36:43 GMT, Viktor Klang  wrote:

> This PR reverts the deactivation changes of the updates to FJP introduced in JDK-8319447.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24473#pullrequestreview-2746919024

From alanb at openjdk.org  Mon Apr  7 14:09:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 7 Apr 2025 14:09:59 GMT
Subject: RFR: 8352971: Increase maximum number of hold counts for
 ReentrantReadWriteLock [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 7 Apr 2025 13:55:27 GMT, Viktor Klang  wrote:

>> I'm breaking this change out as a separate improvement, since it will not be generally possible to adjust these limits on the j.u.c primitives since they might already use a backing `long` to pack in information which needs to be updated atomically (would require 128-bit atomics to widen them, and it still infeasible to change return types of pre-existing APIs).
>
> Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Make sure that the test fails in case of an InterruptedException
>  - Adding support for more than 65k readers and writers of ReentrantReadWriteLock

Marked as reviewed by alanb (Reviewer).

test/jdk/java/util/concurrent/tck/ReentrantReadWriteLock20Test.java line 93:

> 91:             while ((next = threads.pollFirst()) != null) {
> 92:                 while (next.isAlive()) {
> 93:                     next.join();

You can drop the inner-while as join will wait for the thread to terminate, no-op if already terminated.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24261#pullrequestreview-2746959737
PR Review Comment: https://git.openjdk.org/jdk/pull/24261#discussion_r2031322960

From mli at openjdk.org  Mon Apr  7 14:28:12 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 7 Apr 2025 14:28:12 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L
Message-ID: 

Hi,
Can you help to review this patch?
On riscv, CMoveI/L already were implemented, but there are some gap:
1. CMoveI/L does not support comparison with float/double, corresponding tests are not turn on either.
2. Some optimization of C2 is not turned on, e.g. `Phi -> CMove -> min_max`.
3. lack of some corresponding performance tests.

Also there are some issue with current Zicond:
1. UseZicond is turned on automatically by hwprobe, but jmh tests show that it's not always bring benefit, in some situation it even brings regression, the reason is the generated code by Zicond is much larger than branch version, in particular when it's in a loop and unrolled.

This patch on riscv is to:
1. add CMoveI/L comparing float/double, and corresponding tests,
2. enable more C2 optimization,
3. add more benchmark tests,
4. turn off UseZicond by default.

Thanks!

-------------

Commit messages:
 - turn off flag Zicond by default
 - remove
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/24490/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24490&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352504
  Stats: 951 lines in 15 files changed: 912 ins; 10 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/24490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24490/head:pull/24490

PR: https://git.openjdk.org/jdk/pull/24490

From clanger at openjdk.org  Mon Apr  7 14:49:45 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 7 Apr 2025 14:49:45 GMT
Subject: RFR: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public [v3]
In-Reply-To: 
References: 
Message-ID: <7hBJDSmbUU_s0dAxVBrd1Tdrz8bj8BgsPAGTCImKirU=.06b0dcc1-05c2-4905-89dd-896258111c6b@github.com>

> Alternative approach to #24012
> 
> This keeps the current handling of *.pdb vs *.stripped.pdb which allows debugging at the cost of a little hack in jlink. Maybe the code in jlink can be improved, e.g. make it more conditional.
> 
> I'm running this through our testing still to see whether it'll resolve all of the test issues and does not introduce regressions.

Christoph Langer 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-8351842-alternative
 - Merge branch 'master' into JDK-8351842-alternative
 - Extract fix for building debug symbols bundle
 - JDK-8351842

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24057/files
  - new: https://git.openjdk.org/jdk/pull/24057/files/da632788..b0f564e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24057&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24057&range=01-02

  Stats: 8674 lines in 195 files changed: 6185 ins; 2073 del; 416 mod
  Patch: https://git.openjdk.org/jdk/pull/24057.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24057/head:pull/24057

PR: https://git.openjdk.org/jdk/pull/24057

From vklang at openjdk.org  Mon Apr  7 15:05:02 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 7 Apr 2025 15:05:02 GMT
Subject: RFR: 8352971: Increase maximum number of hold counts for
 ReentrantReadWriteLock [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 7 Apr 2025 14:03:13 GMT, Alan Bateman  wrote:

>> Viktor Klang 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:
>> 
>>  - Make sure that the test fails in case of an InterruptedException
>>  - Adding support for more than 65k readers and writers of ReentrantReadWriteLock
>
> test/jdk/java/util/concurrent/tck/ReentrantReadWriteLock20Test.java line 93:
> 
>> 91:             while ((next = threads.pollFirst()) != null) {
>> 92:                 while (next.isAlive()) {
>> 93:                     next.join();
> 
> You can drop the inner-while as join will wait for the thread to terminate, no-op if already terminated.

I'll leave it as-is for now ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24261#discussion_r2031448070

From vklang at openjdk.org  Mon Apr  7 15:06:35 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 7 Apr 2025 15:06:35 GMT
Subject: Integrated: 8353659: SubmissionPublisherTest::testCap1Submit times out
In-Reply-To: 
References: 
Message-ID: 

On Sun, 6 Apr 2025 12:36:43 GMT, Viktor Klang  wrote:

> This PR reverts the deactivation changes of the updates to FJP introduced in JDK-8319447.

This pull request has now been integrated.

Changeset: 40210333
Author:    Viktor Klang 
URL:       https://git.openjdk.org/jdk/commit/402103331bcdb1055f89c938fdd6b1df772993b6
Stats:     13 lines in 2 files changed: 2 ins; 4 del; 7 mod

8353659: SubmissionPublisherTest::testCap1Submit times out

Reviewed-by: dl, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/24473

From rriggs at openjdk.org  Mon Apr  7 15:13:01 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 7 Apr 2025 15:13:01 GMT
Subject: RFR: 8353267: jmod create finds the wrong set of packages when
 class file are in non-package location
In-Reply-To: <1ECZmIwkZ3iCpm_33bJxUO-GmFQwc0hqbwr9OQ2ljWo=.1cc1f217-6231-4ebf-a0aa-d8153b31e189@github.com>
References: <1ECZmIwkZ3iCpm_33bJxUO-GmFQwc0hqbwr9OQ2ljWo=.1cc1f217-6231-4ebf-a0aa-d8153b31e189@github.com>
Message-ID: 

On Tue, 1 Apr 2025 17:33:43 GMT, Alan Bateman  wrote:

> `jmod create` maps the contents of the module to a set of packages. This mapping derives illegal package names when class resources are located in non-package locations, e.g. in the META-INF tree. `jlink` also has an issue in this area and doesn't correctly determine if a resource is in a named package when the resource is class file in a non-package location.

Looks fine except for a possible improvement of an exception message to better cover a new case.

src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 752:

> 750:          * Throws IOException for a .class file that is not module-info.class.
> 751:          */
> 752:         private void ensureNotClassFile(String name) {

The mention of the "unnamed package" may not always be applicable.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24362#pullrequestreview-2747192692
PR Review Comment: https://git.openjdk.org/jdk/pull/24362#discussion_r2031461542

From alanb at openjdk.org  Mon Apr  7 15:26:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 7 Apr 2025 15:26:54 GMT
Subject: RFR: 8353267: jmod create finds the wrong set of packages when
 class file are in non-package location
In-Reply-To: 
References: <1ECZmIwkZ3iCpm_33bJxUO-GmFQwc0hqbwr9OQ2ljWo=.1cc1f217-6231-4ebf-a0aa-d8153b31e189@github.com>
 
Message-ID: 

On Mon, 7 Apr 2025 15:08:56 GMT, Roger Riggs  wrote:

>> `jmod create` maps the contents of the module to a set of packages. This mapping derives illegal package names when class resources are located in non-package locations, e.g. in the META-INF tree. `jlink` also has an issue in this area and doesn't correctly determine if a resource is in a named package when the resource is class file in a non-package location.
>
> src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 752:
> 
>> 750:          * Throws IOException for a .class file that is not module-info.class.
>> 751:          */
>> 752:         private void ensureNotClassFile(String name) {
> 
> The mention of the "unnamed package" may not always be applicable.

module-info.class aside, all classes in a named module must be in a named package so the exception message is correct. Or maybe you mean something else?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24362#discussion_r2031492041

From pminborg at openjdk.org  Mon Apr  7 16:00:41 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 7 Apr 2025 16:00:41 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v51]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo in return type

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/111f4d0d..5bb5e48a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=50
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=49-50

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From rriggs at openjdk.org  Mon Apr  7 16:11:51 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 7 Apr 2025 16:11:51 GMT
Subject: RFR: 8353267: jmod create finds the wrong set of packages when
 class file are in non-package location
In-Reply-To: <1ECZmIwkZ3iCpm_33bJxUO-GmFQwc0hqbwr9OQ2ljWo=.1cc1f217-6231-4ebf-a0aa-d8153b31e189@github.com>
References: <1ECZmIwkZ3iCpm_33bJxUO-GmFQwc0hqbwr9OQ2ljWo=.1cc1f217-6231-4ebf-a0aa-d8153b31e189@github.com>
Message-ID: <49BpRPPpan81zlTY6d8tAdQK4Dl5Dku7uRiUiFivN9c=.84771340-8637-463c-acdb-f9a00c59dc77@github.com>

On Tue, 1 Apr 2025 17:33:43 GMT, Alan Bateman  wrote:

> `jmod create` maps the contents of the module to a set of packages. This mapping derives illegal package names when class resources are located in non-package locations, e.g. in the META-INF tree. `jlink` also has an issue in this area and doesn't correctly determine if a resource is in a named package when the resource is class file in a non-package location.

looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24362#pullrequestreview-2747383175

From iklam at openjdk.org  Mon Apr  7 16:18:59 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 7 Apr 2025 16:18:59 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v4]
In-Reply-To: <_jUyfQOHTQHeuKp72nHVOjSJJZtmjx-6ViBd9qi-IpA=.06a4213b-7834-4eda-b50f-4d362bbb761c@github.com>
References: 
 <_jUyfQOHTQHeuKp72nHVOjSJJZtmjx-6ViBd9qi-IpA=.06a4213b-7834-4eda-b50f-4d362bbb761c@github.com>
Message-ID: 

On Mon, 7 Apr 2025 07:46:52 GMT, Timofei Pushkin  wrote:

>> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app.
>> 
>> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible.
>
> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't use URLClassPath

src/hotspot/share/cds/classListParser.cpp line 534:

> 532:   GrowableArray specified_interfaces = get_specified_interfaces();
> 533: 
> 534:   const char* source_path = ClassLoader::uri_to_path(_source);

Is `ClassLoader::uri_to_path` necessary? I think `_source` is already a file path.

src/hotspot/share/cds/unregisteredClasses.cpp line 87:

> 85:                             CHECK_NULL);
> 86:     assert(result.get_type() == T_OBJECT, "just checking");
> 87:     obj = result.get_oop();

There's no need to put the above code in its own scope. Maybe do the following instead?


return InstanceKlass::cast(java_lang_Class::as_Klass(result.get_oop()));

src/java.base/share/classes/jdk/internal/misc/CDS.java line 444:

> 442:         protected Class findClass(String name) throws ClassNotFoundException {
> 443:             // Unregistered classes should be found in load(...), registered classes should be
> 444:             // handeled by parent loaders

Hmm, I wonder how the reference to java.lang.Object is resolved in this case. When `CustomLoadee` is parsed, the ClassFileParser needs to resolve is super class, which should result into a call to `UnregisteredClassLoader::findClass()`.


            "java/lang/Object id: 0",
            "CustomLoadee id: 1 super: 0 source: .",

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2031561175
PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2031573550
PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2031586035

From vklang at openjdk.org  Mon Apr  7 16:19:16 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 7 Apr 2025 16:19:16 GMT
Subject: Integrated: 8352971: Increase maximum number of hold counts for
 ReentrantReadWriteLock
In-Reply-To: 
References: 
Message-ID: 

On Wed, 26 Mar 2025 16:19:16 GMT, Viktor Klang  wrote:

> I'm breaking this change out as a separate improvement, since it will not be generally possible to adjust these limits on the j.u.c primitives since they might already use a backing `long` to pack in information which needs to be updated atomically (would require 128-bit atomics to widen them, and it still infeasible to change return types of pre-existing APIs).

This pull request has now been integrated.

Changeset: 867a0301
Author:    Viktor Klang 
URL:       https://git.openjdk.org/jdk/commit/867a0301893cbf3d5434e4966d27d7f4913afb98
Stats:     140 lines in 4 files changed: 105 ins; 0 del; 35 mod

8352971: Increase maximum number of hold counts for ReentrantReadWriteLock

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/24261

From naoto at openjdk.org  Mon Apr  7 16:30:49 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 7 Apr 2025 16:30:49 GMT
Subject: RFR: 8353713: Improve Currency.getInstance exception handling [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 4 Apr 2025 23:03:23 GMT, Justin Lu  wrote:

>> Please review this PR which improves some Currency `IllegalArgumentException`s by including the input in the message. This could be a currency code, country code, or locale. This change also includes tests to check the messages for an invalid country via the region override as well as an invalid country code within a 3 length currency code.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naoto's review -> use str literal since not param test

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24459#pullrequestreview-2747430868

From lancea at openjdk.org  Mon Apr  7 16:41:48 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 7 Apr 2025 16:41:48 GMT
Subject: RFR: 8353787: Increased number of SHA-384-Digest
 java.util.jar.Attributes$Name instances leading to higher memory footprint
In-Reply-To: 
References: 
Message-ID: 

On Mon, 7 Apr 2025 06:34:11 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this change which proposes to address the increase in memory footprint of an application that uses signed JAR files, signed with `SHA-384` digest algorithm? This addresses https://bugs.openjdk.org/browse/JDK-8353787.
> 
> As noted in that issue and the linked mailing list discussion, it has been noticed that when JARs signed with `SHA-384` digest algorithm (which is the default since Java 19) are loaded, the number of `java.util.Attributes$Name` instances held in memory increase, leading to an increase in the memory footprint of the application.
> 
> The `Attributes` class has an internal cache which is meant to store `Name` instances of some well-known manifest attributes. It already has the `Name` instances for `SHA1-Digest` and `SHA-256-Digest` manifest attributes cached, but is missing an entry for `SHA-384-Digest`. The commit in this PR adds `SHA-384-Digest` to that cache.
> 
> Given the nature of this change, no new jtreg test has been introduced and existing tests in tier1, tier2 and tier3 continue to pass with this change. I've manually verified that this change does reduce the memory footprint of an application which has signed JARs with `SHA-384` digest algorithm  (details in a comment of this PR).

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24475#pullrequestreview-2747458624

From kvn at openjdk.org  Mon Apr  7 17:05:59 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 7 Apr 2025 17:05:59 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
In-Reply-To: 
References: 
Message-ID: 

On Fri, 4 Apr 2025 22:52:24 GMT, Vladimir Ivanov  wrote:

> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
> 
> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
> 
> The patch consists of the following parts:
>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
> 
> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
> 
> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
> 
> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
> 
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
> 
> Thanks!

Few questions?

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/CPUFeatures.java line 60:

> 58:     }
> 59: 
> 60:     public static class X64 {

Should we create `src/jdk.incubator.vector/cpu/` for CPU specific information? As separate refactoring.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 100:

> 98: 
> 99:     /**
> 100:      * Naming convention in SVML vector math library.

Does this library has code for all AVX configurations?

-------------

PR Review: https://git.openjdk.org/jdk/pull/24462#pullrequestreview-2747510895
PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2031654383
PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2031657213

From smarks at openjdk.org  Mon Apr  7 17:17:57 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 7 Apr 2025 17:17:57 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sat, 5 Apr 2025 02:31:21 GMT, Chen Liang  wrote:

>> src/java.base/share/classes/java/lang/IO.java line 122:
>> 
>>> 120:     public static void print(Object obj) {
>>> 121:         System.out.print(obj);
>>> 122:         System.out.flush();
>> 
>> Is it worth using a local variable to avoid calling `print` and `flush` on different streams in case `System.out` is reassigned in between?
>> 
>> 
>> var out = System.out;
>> out.print(obj);
>> out.flush();
>
> This code is not that perf sensitive, guess it is fine as-is

I think there's a correctness angle. If you print something to a stream you want to flush the same stream. If System.out is changed in between (unlikely, but possible) then output destined for the old stream could be stranded in its buffer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2031674696

From rriggs at openjdk.org  Mon Apr  7 17:18:40 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 7 Apr 2025 17:18:40 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v7]
In-Reply-To: 
References: 
Message-ID: 

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions.
  Remove dead code from ForkJoinPool.
  Add @SuppressWarnings("remove")

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24444/files
  - new: https://git.openjdk.org/jdk/pull/24444/files/9a9417a7..322c5938

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=05-06

  Stats: 20 lines in 4 files changed: 11 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444

PR: https://git.openjdk.org/jdk/pull/24444

From naoto at openjdk.org  Mon Apr  7 17:26:03 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 7 Apr 2025 17:26:03 GMT
Subject: RFR: 8351740: Clean up some code around initialization of encoding
 properties
In-Reply-To: 
References: 
Message-ID: 

On Fri, 4 Apr 2025 23:42:26 GMT, Stuart Marks  wrote:

> Some of the code that creates various encoding properties at JVM initialization time, such as file.encoding and native.encoding, could use some cleaning up. Cleanup is fairly minimal and should be mostly behavior-preserving. Changes include the following:
> 
> * In the java_props.h and java_props_md.c files, add documentation and asserts that the sprops.encoding and sprops.sun_jnu_encoding members are always set to non-NULL by the platform-specific code.
> 
> * In SystemProps.java, remove a null check that is now extraneous based on the above assertion.
> 
> * In SystemProps.java, rearrange logic (with no behavior change) around handling of the "COMPAT" value for the file.encoding property.
> 
> * In SystemProps.Raw, rename the platform properties array index from _file_encoding_NDX to _native_encoding_NDX.
> 
> * In SystemProps.Raw.cmdProperties(), adjust the HashMap size computation. This should actually avoid resizing of the HashMap (unlike the earlier code).
> 
> * Adjust various comments in several places for clarity and correctness.

Thanks for the clean-up. Changing the index name from `_file_encoding_NDX` to `_native_encoding_NDX` really helps.

src/java.base/share/native/libjava/System.c line 153:

> 151:     /*
> 152:      * Since sun_jnu_encoding is now hard-coded to UTF-8 on Mac, we don't
> 153:      * want to use it to overwrite file.encoding

This `file.encoding` can also be renamed. Should have been done with JEP 400

-------------

PR Review: https://git.openjdk.org/jdk/pull/24463#pullrequestreview-2747544328
PR Review Comment: https://git.openjdk.org/jdk/pull/24463#discussion_r2031675274

From smarks at openjdk.org  Mon Apr  7 17:28:52 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 7 Apr 2025 17:28:52 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods
In-Reply-To: 
References: 
 <49kjZQWwnSD9GEJTcXjwNSl6socEa0lOiQCr2M5Mmu8=.6a986db6-5a07-4811-bdc2-2e513c2e2f65@github.com>
 
Message-ID: 

On Mon, 7 Apr 2025 07:01:56 GMT, Jan Lahoda  wrote:

>> src/java.base/share/classes/java/lang/IO.java line 183:
>> 
>>> 181:      * @return the internal BufferedReader instance
>>> 182:      */
>>> 183:     static synchronized BufferedReader reader() {
>> 
>> Is the lock only inteneded for initialization, i.e. should it apply for simply getting the reader?
>
> I believe there needs to be some barriers (at least `volatile`) even for getting the already initialized reader. And then, given the code here, it is probably fine and less error prone to simply use `synchronized` that something more complex.
> 
> But, given we'll hopefully have `@StableValue` soon, maybe we could use that? What do you think @stuart-marks?
> 
> Thanks!

It's even more complex than `volatile`. If a thread comes along and reads a null here, it still needs to take a lock (or something) to prevent more than one thread from creating the BufferedReader and storing it back into the field. This leads down the path of double-checked locking, initialize-on-demand holder, etc.

It's not clear to me this is in such a critical path that it warrants adding any of this stuff. StableValue probably has the right semantics. However, it's not even in the JDK yet (though it is Targeted to 25 as of this moment). But I don't think we want to add a dependency on a Preview API.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2031689379

From alanb at openjdk.org  Mon Apr  7 17:33:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 7 Apr 2025 17:33:50 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 7 Apr 2025 13:35:57 GMT, Severin Gehwolf  wrote:

>> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
>> 
>> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
>> 
>> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
>> 2. For those files the hash sum checks are skipped.
>> 
>> **Testing**
>> 
>> - [x] GHA
>> - [x] `jdk/tools/jlink` jtreg tests (also on [GHA](https://github.com/jerboaa/jdk/actions/runs/14308729271))
>> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review v2

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/LinkableRuntimeImage.java line 71:

> 69:     private static InputStream getDiffInputStream(String module) throws IOException {
> 70:         String resourceName = String.format(DIFF_PATTERN, module);
> 71:         return JDK_JLINK_MOD.getResourceAsStream(resourceName);

FYI you can use LinkableRuntimeImage.class.getResourceAsStream here as the resource is in the current module.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2031696600

From liach at openjdk.org  Mon Apr  7 17:46:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Apr 2025 17:46:51 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
In-Reply-To: 
References: 
Message-ID: 

On Fri, 4 Apr 2025 22:52:24 GMT, Vladimir Ivanov  wrote:

> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
> 
> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
> 
> The patch consists of the following parts:
>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
> 
> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
> 
> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
> 
> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
> 
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
> 
> Thanks!

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/CPUFeatures.java line 44:

> 42:         String featuresString = VectorSupport.getCPUFeatures();
> 43:         debug(featuresString);
> 44:         String[] features = featuresString.toLowerCase().split(", "); // ", " is used as a delimiter

Please use `toLowerCase(Locale.ROOT)`: if the system locale is turkish, `I` and dotless i are two letters, and the dotless i will fail in the subsequent `validateFeatures` assertion. Same for `hasFeature`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2031714743

From smarks at openjdk.org  Mon Apr  7 18:13:29 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 7 Apr 2025 18:13:29 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v2]
In-Reply-To: 
References: 
 
Message-ID: <909XG6FIuGBpfgkT4MB_wFynaR1MXvsnnqmdH6EYGZA=.85a20509-8d5b-4df6-a58c-fdcbf11fe596@github.com>

On Mon, 7 Apr 2025 09:12:27 GMT, Alan Bateman  wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use local variable for System.out in print().
>
> src/java.base/share/classes/java/lang/IO.java line 45:
> 
>> 43:  * UTF-8 is used instead. These internal objects are created upon the first call to
>> 44:  * either of the {@code readln} methods and are stored for subsequent reuse by these
>> 45:  * methods.
> 
> @stuart-marks Can we rephrase this paragraph so that it doesn't use phrase "internal objects"? The class does speak of buffering and how it might impact code that mixes use of System.in and IO.readln so I agree with that part it's just the "internal objects" phrase that is confusing to read in this class.

I used "internal objects" because I wanted to avoid naming concrete classes, which might or might not be used. Previous drafts mentioned BufferedReader, InputStreamReader, and CharsetDecoder.

I could replace "internal objects" with something more descriptive like "objects to handle buffering and charset decoding" but I'd still need a noun phrase to refer to them later. Maybe "buffering and decoding objects" ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2031754279

From smarks at openjdk.org  Mon Apr  7 18:13:30 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 7 Apr 2025 18:13:30 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 5 Apr 2025 00:55:55 GMT, Luca Kellermann  wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use local variable for System.out in print().
>
> src/java.base/share/classes/java/lang/IO.java line 122:
> 
>> 120:     public static void print(Object obj) {
>> 121:         System.out.print(obj);
>> 122:         System.out.flush();
> 
> Is it worth using a local variable to avoid calling `print` and `flush` on different streams in case `System.out` is reassigned in between?
> 
> 
> var out = System.out;
> out.print(obj);
> out.flush();

Updated as suggested; thanks @lukellmann .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2031757221

From jlahoda at openjdk.org  Mon Apr  7 18:13:29 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 7 Apr 2025 18:13:29 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v2]
In-Reply-To: 
References: 
Message-ID: 

> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
> - `java. ... .IO` is no longer automatically imported in any compilation unit
> - the feature is finalized (i.e. no longer requires `--enable-preview`)

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Use local variable for System.out in print().

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24438/files
  - new: https://git.openjdk.org/jdk/pull/24438/files/a5d223e1..be8846e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24438.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24438/head:pull/24438

PR: https://git.openjdk.org/jdk/pull/24438

From naoto at openjdk.org  Mon Apr  7 18:13:30 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 7 Apr 2025 18:13:30 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 7 Apr 2025 18:10:20 GMT, Jan Lahoda  wrote:

>> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
>> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
>> - `java. ... .IO` is no longer automatically imported in any compilation unit
>> - the feature is finalized (i.e. no longer requires `--enable-preview`)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use local variable for System.out in print().

test/jdk/java/lang/IO/IO/IO.java line 1:

> 1: /*

Is there reason to create a test subdirectory `IO` under `java.lang.IO` package?

test/jdk/java/lang/IO/IO/IO.java line 53:

> 51: /*
> 52:  * @test
> 53:  * @bug 8305457 8342936 8351435

Issue id needs to be added (and other test files too)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2031735643
PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2031750501

From smarks at openjdk.org  Mon Apr  7 18:38:22 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 7 Apr 2025 18:38:22 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 7 Apr 2025 09:18:37 GMT, Alan Bateman  wrote:

>> This implementation is not to be emulated by beginners. If an Exception.is thrown here, a user might be tempted to add handlers in their code, while this is an issue with the setup.
>
> Someone is bound to ask why the readln method throw but the println methods don't.

The IOError was carried over from Console.readLine(), which throws IOError on error. Of course we're decoupled from Console now, but that was the original reason.

My guess is that Console methods throw IOError because (a) they didn't want to make everybody catch IOException, (b) they didn't want to maintain an internal error state like PrintStream, and (c) they wanted to throw a throwable whose type conveyed the meaning that it wasn't expected to be handled. IOError and Console were both added in JDK 1.6. Maybe that reasoning still applies here.

UncheckedIOException wasn't added until JDK 1.8. Note also that UncheckedIOException has a cause of IOException, so it can't arise from some other throwable. This was used in the previous implementation, where IOError was thrown if Console was null. That doesn't apply anymore, but IOError is still somewhat more flexible than UncheckedIOException in this regard.

I think we need to say something, implicitly or explicitly, about error handling. Note that PrintStream has this internal error state so output is covered already. For input it seems like IOError is reasonable, but maybe there's a better choice.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2031782109

From rriggs at openjdk.org  Mon Apr  7 18:40:35 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 7 Apr 2025 18:40:35 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v8]
In-Reply-To: 
References: 
Message-ID: 

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

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:

 - Revert "Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions."
   SecureClassLoader.getPermissions and URLClassLoader.getPermissions are not marked as Deprecated.
 - Merge branch 'master' into 8353641-deprecate-premission-classes
 - Missing suppresswarnings
 - Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions.
   Remove dead code from ForkJoinPool.
   Add @SuppressWarnings("remove")
 - Remove unnecessary SuppressWarnings and correct Deprecated annotation style
 - Update copyright in WindowsFileCopy
 - Remove unused import of LinkPermission
 - Updated style of @Deprecated to match most existing @Deprecated annotations
   `since` comes before `forRemoval`
   No spaces around `=`
 - Add SuppressWarnings to a Windows source missed earlier.
 - 8353641: Deprecate core library permission classes for removal
   
   Now that the Security Manager is permanently disabled, the following permission classes
   in the core libraries area can be deprecated for removal as they are no longer useful:
   FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission,
   RuntimePermission, and SerializablePermission
   
   @Deprecated(forRemoval = true, since="25")
   Is added to each class and the existing @apiNote is converted to @deprected

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24444/files
  - new: https://git.openjdk.org/jdk/pull/24444/files/322c5938..6d3f003d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=06-07

  Stats: 10986 lines in 240 files changed: 8087 ins; 2384 del; 515 mod
  Patch: https://git.openjdk.org/jdk/pull/24444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444

PR: https://git.openjdk.org/jdk/pull/24444

From liach at openjdk.org  Mon Apr  7 19:09:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Apr 2025 19:09:15 GMT
Subject: RFR: 8066583: DeflaterInput/OutputStream and
 InflaterInput/OutputStream should explain responsibility for freeing resources
 [v10]
In-Reply-To: 
References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com>
 
Message-ID: <3QhHlrLfQomPiwwWGC2FqOXv6ZZj3WiWOIi66RCrzRk=.503f0d62-18f9-44e8-a2b9-740e454cdefb@github.com>

On Mon, 7 Apr 2025 09:05:36 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`.
>> 
>> The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes.
>> 
>> I'll draft a CSR once we agree on the proposed text.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   "a" instead of "the"

You should finalize the CSR for review too.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23655#pullrequestreview-2747817565

From liach at openjdk.org  Mon Apr  7 19:20:22 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Apr 2025 19:20:22 GMT
Subject: RFR: 8350462: MethodTypeForm.LF_INTERPRET can cache the MemberName
 instead [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sun, 6 Apr 2025 08:05:42 GMT, Zihao Lin  wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java line 71:
>> 
>>> 69:     // Indexes into lambdaForms:
>>> 70:     static final int
>>> 71:             LF_INVVIRTUAL              =  0,  // DMH invokeVirtual
>> 
>> You can remove the LF_INTERPRET constant from this list.
>
> OK, removed it.

Now the index 6 is left unused in the LF cache array - we can leave it empty and renumber the cache indices when we add a new entry to cache.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24468#discussion_r2031863311

From liach at openjdk.org  Mon Apr  7 19:20:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Apr 2025 19:20:21 GMT
Subject: RFR: 8350462: MethodTypeForm.LF_INTERPRET can cache the MemberName
 instead [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 6 Apr 2025 08:09:27 GMT, Zihao Lin  wrote:

>> Modify the cache in MethodTypeForm that currently stores the LF_INTERPRET Lambda form. Instead of caching the entire LambdaForm, change it to store a SoftReference. This will avoid unnecessary memory usage.
>
> Zihao Lin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove LF_INTERPRET

I shall run hs-tier2 before approving, in case mainline leyden doesn't work with WeakReferences.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24468#issuecomment-2784377122

From vromero at openjdk.org  Mon Apr  7 19:20:22 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 7 Apr 2025 19:20:22 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v2]
In-Reply-To: 
References: 
 
Message-ID: <6w1YXrCnHGH5VifP_2jWinbKd0sGMlUeR1KOC8FJWXg=.af36af50-a7e7-4e76-9470-6a89bf58cf3e@github.com>

On Mon, 7 Apr 2025 18:13:29 GMT, Jan Lahoda  wrote:

>> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
>> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
>> - `java. ... .IO` is no longer automatically imported in any compilation unit
>> - the feature is finalized (i.e. no longer requires `--enable-preview`)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use local variable for System.out in print().

javac compiler related code and tests lgtm

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24438#pullrequestreview-2747868909

From liach at openjdk.org  Mon Apr  7 19:25:19 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Apr 2025 19:25:19 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v2]
In-Reply-To: <909XG6FIuGBpfgkT4MB_wFynaR1MXvsnnqmdH6EYGZA=.85a20509-8d5b-4df6-a58c-fdcbf11fe596@github.com>
References: 
 
 <909XG6FIuGBpfgkT4MB_wFynaR1MXvsnnqmdH6EYGZA=.85a20509-8d5b-4df6-a58c-fdcbf11fe596@github.com>
Message-ID: <-ujytXA8SPaWsJYJCUTMKo1Bd43qrBqTeGvM3a1vF98=.ecc2c4ec-317b-4a12-9a31-68ca8a4e159a@github.com>

On Mon, 7 Apr 2025 18:08:29 GMT, Stuart Marks  wrote:

>> src/java.base/share/classes/java/lang/IO.java line 45:
>> 
>>> 43:  * UTF-8 is used instead. These internal objects are created upon the first call to
>>> 44:  * either of the {@code readln} methods and are stored for subsequent reuse by these
>>> 45:  * methods.
>> 
>> @stuart-marks Can we rephrase this paragraph so that it doesn't use phrase "internal objects"? The class does speak of buffering and how it might impact code that mixes use of System.in and IO.readln so I agree with that part it's just the "internal objects" phrase that is confusing to read in this class.
>
> I used "internal objects" because I wanted to avoid naming concrete classes, which might or might not be used. Previous drafts mentioned BufferedReader, InputStreamReader, and CharsetDecoder.
> 
> I could replace "internal objects" with something more descriptive like "objects to handle buffering and charset decoding" but I'd still need a noun phrase to refer to them later. Maybe "buffering and decoding objects" ?

Can we rephrase the 1st sentence to read:
"The `readln()` and `readln(String)` methods in this class decode bytes read from `System.in` into characters."

And remove the last "these internal objects" sentence.

And for the next paragraph, change the first line to:
"The `readln` methods may buffer additional bytes..."

So we remove references to "internal objects."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2031815564

From liach at openjdk.org  Mon Apr  7 19:27:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Apr 2025 19:27:13 GMT
Subject: RFR: 8349176: Speed up Integer/Long.toString via
 StringConcatHelper::newArray [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 5 Apr 2025 01:19:39 GMT, Shaojin Wen  wrote:

>> The byte[] allocated in Integer/Long.toString is fully filled, so we can use StringConcatHelper::newArray to create byte[] to improve performance.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use StringConcatHelper.newArray

We might defer reviewing this after we have re-examined DecimalDigits. Please be patient.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23353#issuecomment-2784413241

From smarks at openjdk.org  Mon Apr  7 19:47:21 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 7 Apr 2025 19:47:21 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v2]
In-Reply-To: <-ujytXA8SPaWsJYJCUTMKo1Bd43qrBqTeGvM3a1vF98=.ecc2c4ec-317b-4a12-9a31-68ca8a4e159a@github.com>
References: 
 
 <909XG6FIuGBpfgkT4MB_wFynaR1MXvsnnqmdH6EYGZA=.85a20509-8d5b-4df6-a58c-fdcbf11fe596@github.com>
 <-ujytXA8SPaWsJYJCUTMKo1Bd43qrBqTeGvM3a1vF98=.ecc2c4ec-317b-4a12-9a31-68ca8a4e159a@github.com>
Message-ID: 

On Mon, 7 Apr 2025 18:49:33 GMT, Chen Liang  wrote:

>> I used "internal objects" because I wanted to avoid naming concrete classes, which might or might not be used. Previous drafts mentioned BufferedReader, InputStreamReader, and CharsetDecoder.
>> 
>> I could replace "internal objects" with something more descriptive like "objects to handle buffering and charset decoding" but I'd still need a noun phrase to refer to them later. Maybe "buffering and decoding objects" ?
>
> Can we rephrase the 1st sentence to read:
> "The `readln()` and `readln(String)` methods in this class decode bytes read from `System.in` into characters."
> 
> And remove the last "these internal objects" sentence.
> 
> And for the next paragraph, change the first line to:
> "The `readln` methods may buffer additional bytes..."
> 
> So we remove references to "internal objects."

I'm in the midst of rewriting all of this stuff. The main concern here is that applications can use System.in more or less as they please (presumably without buffering) _until_ the first call to a `readln` method, at which time _something happens_ and effectively the application cannot use System.in anymore. I'll post the revision when I've finished it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2031907101

From jlu at openjdk.org  Mon Apr  7 20:48:17 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 7 Apr 2025 20:48:17 GMT
Subject: Integrated: 8353322: Specification of ChoiceFormat#parse(String,
 ParsePosition) is inadequate
In-Reply-To: 
References: 
Message-ID: 

On Tue, 1 Apr 2025 16:45:26 GMT, Justin Lu  wrote:

> Please review this PR which specifies the `ChoiceFormat#parse(String, ParsePosition)` method. A corresponding CSR is filed. The current specification is simply "Parses a Number from the input text" which does not indicate how the value is returned. The criteria for a match, as well as no match should be made clear.

This pull request has now been integrated.

Changeset: a8dfcf55
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/a8dfcf55849775a7ac4822a8b7661f20f1b33bb0
Stats:     17 lines in 1 file changed: 14 ins; 0 del; 3 mod

8353322: Specification of ChoiceFormat#parse(String, ParsePosition) is inadequate

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/24361

From jlu at openjdk.org  Mon Apr  7 20:48:17 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 7 Apr 2025 20:48:17 GMT
Subject: RFR: 8353322: Specification of ChoiceFormat#parse(String,
 ParsePosition) is inadequate [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 2 Apr 2025 19:46:12 GMT, Justin Lu  wrote:

>> Please review this PR which specifies the `ChoiceFormat#parse(String, ParsePosition)` method. A corresponding CSR is filed. The current specification is simply "Parses a Number from the input text" which does not indicate how the value is returned. The criteria for a match, as well as no match should be made clear.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's review - Improve first sentence

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24361#issuecomment-2784586618

From jlahoda at openjdk.org  Mon Apr  7 21:07:36 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 7 Apr 2025 21:07:36 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v3]
In-Reply-To: 
References: 
Message-ID: 

> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
> - `java. ... .IO` is no longer automatically imported in any compilation unit
> - the feature is finalized (i.e. no longer requires `--enable-preview`)

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Rewrite bits about charset decoding, removing mention of "internal objects."

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24438/files
  - new: https://git.openjdk.org/jdk/pull/24438/files/be8846e0..33e280df

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=01-02

  Stats: 27 lines in 1 file changed: 11 ins; 8 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/24438.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24438/head:pull/24438

PR: https://git.openjdk.org/jdk/pull/24438

From smarks at openjdk.org  Mon Apr  7 21:07:36 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 7 Apr 2025 21:07:36 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v3]
In-Reply-To: 
References: 
 
 <909XG6FIuGBpfgkT4MB_wFynaR1MXvsnnqmdH6EYGZA=.85a20509-8d5b-4df6-a58c-fdcbf11fe596@github.com>
 <-ujytXA8SPaWsJYJCUTMKo1Bd43qrBqTeGvM3a1vF98=.ecc2c4ec-317b-4a12-9a31-68ca8a4e159a@github.com>
 
Message-ID: 

On Mon, 7 Apr 2025 19:44:40 GMT, Stuart Marks  wrote:

>> Can we rephrase the 1st sentence to read:
>> "The `readln()` and `readln(String)` methods in this class decode bytes read from `System.in` into characters."
>> 
>> And remove the last "these internal objects" sentence.
>> 
>> And for the next paragraph, change the first line to:
>> "The `readln` methods may buffer additional bytes..."
>> 
>> So we remove references to "internal objects."
>
> I'm in the midst of rewriting all of this stuff. The main concern here is that applications can use System.in more or less as they please (presumably without buffering) _until_ the first call to a `readln` method, at which time _something happens_ and effectively the application cannot use System.in anymore. I'll post the revision when I've finished it.

Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2032003160

From vlivanov at openjdk.org  Mon Apr  7 21:37:33 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 7 Apr 2025 21:37:33 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
> 
> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
> 
> The patch consists of the following parts:
>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
> 
> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
> 
> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
> 
> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
> 
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
> 
> Thanks!

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Reviews and Float64Vector-related fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24462/files
  - new: https://git.openjdk.org/jdk/pull/24462/files/fc27aee5..368b943e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=00-01

  Stats: 22 lines in 2 files changed: 5 ins; 6 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/24462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24462/head:pull/24462

PR: https://git.openjdk.org/jdk/pull/24462

From jlu at openjdk.org  Mon Apr  7 21:56:16 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 7 Apr 2025 21:56:16 GMT
Subject: Integrated: 8353585: Provide ChoiceFormat#parse(String,
 ParsePosition) tests
In-Reply-To: 
References: 
Message-ID: 

On Wed, 2 Apr 2025 22:27:14 GMT, Justin Lu  wrote:

> Please review this PR which provides unit tests for `ChoiceFormat#parse(String, ParsePosition)` to check default, multi match, and no match behavior. There were no existing relevant tests.

This pull request has now been integrated.

Changeset: fd2734e9
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/fd2734e97d3ef505473938109746ae59d5fefca6
Stats:     76 lines in 1 file changed: 76 ins; 0 del; 0 mod

8353585: Provide ChoiceFormat#parse(String, ParsePosition) tests

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/24395

From vlivanov at openjdk.org  Mon Apr  7 23:03:03 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 7 Apr 2025 23:03:03 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
> 
> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
> 
> The patch consists of the following parts:
>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
> 
> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
> 
> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
> 
> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
> 
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
> 
> Thanks!

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  features_string -> cpu_info_string

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24462/files
  - new: https://git.openjdk.org/jdk/pull/24462/files/368b943e..9a8f6200

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=01-02

  Stats: 26 lines in 8 files changed: 1 ins; 0 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/24462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24462/head:pull/24462

PR: https://git.openjdk.org/jdk/pull/24462

From vlivanov at openjdk.org  Mon Apr  7 23:25:26 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 7 Apr 2025 23:25:26 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 7 Apr 2025 17:44:33 GMT, Chen Liang  wrote:

>> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   features_string -> cpu_info_string
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/CPUFeatures.java line 44:
> 
>> 42:         String featuresString = VectorSupport.getCPUFeatures();
>> 43:         debug(featuresString);
>> 44:         String[] features = featuresString.toLowerCase().split(", "); // ", " is used as a delimiter
> 
> Please use `toLowerCase(Locale.ROOT)`: if the system locale is turkish, `I` and dotless i are two letters, and the dotless i will fail in the subsequent `validateFeatures` assertion. Same for `hasFeature`.

Good point. Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2032135321

From vlivanov at openjdk.org  Mon Apr  7 23:25:27 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 7 Apr 2025 23:25:27 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 7 Apr 2025 17:01:19 GMT, Vladimir Kozlov  wrote:

>> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   features_string -> cpu_info_string
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/CPUFeatures.java line 60:
> 
>> 58:     }
>> 59: 
>> 60:     public static class X64 {
> 
> Should we create `src/jdk.incubator.vector/cpu/` for CPU specific information? As separate refactoring.

To clarify: are you suggesting to move platform-specific classes into a separate package or platform-specific location? 

It does make sense to separate platform-specific parts into their own classes once amount of code grows over some limit. For now it doesn't look too attractive since amount of code is very small.

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 100:
> 
>> 98: 
>> 99:     /**
>> 100:      * Naming convention in SVML vector math library.
> 
> Does this library has code for all AVX configurations?

Yes, there are 4 configurations (`-XX:UseAVX=[0..3]`) in total covered by SVML library.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2032132478
PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2032134903

From vlivanov at openjdk.org  Mon Apr  7 23:25:27 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 7 Apr 2025 23:25:27 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v3]
In-Reply-To: <9BCE8xN6SA-cPEc1EtuSsqoYwsHiwp31lJKsraWgYso=.67a97434-ef3c-40ab-b5be-841889fdd97c@github.com>
References: 
 <9BCE8xN6SA-cPEc1EtuSsqoYwsHiwp31lJKsraWgYso=.67a97434-ef3c-40ab-b5be-841889fdd97c@github.com>
Message-ID: 

On Mon, 7 Apr 2025 06:44:16 GMT, Per Minborg  wrote:

>> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   features_string -> cpu_info_string
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 258:
> 
>> 256:         if (LIBRARY.isSupported(op, vspecies)) {
>> 257:             String symbol = LIBRARY.symbolName(op, vspecies);
>> 258:             MemorySegment addr = LOOKUP.find(symbol)
> 
> It is better to use `LOOKUP.findOrThrow()` because it does not require lambda creation.

Thanks, changed as you suggested. I introduced a try-catch block instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2032138430

From vlivanov at openjdk.org  Mon Apr  7 23:32:05 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 7 Apr 2025 23:32:05 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v4]
In-Reply-To: 
References: 
Message-ID: 

> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
> 
> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
> 
> The patch consists of the following parts:
>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
> 
> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
> 
> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
> 
> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
> 
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
> 
> Thanks!

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Fix windows-aarch64 build failure

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24462/files
  - new: https://git.openjdk.org/jdk/pull/24462/files/9a8f6200..bb1a11db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24462/head:pull/24462

PR: https://git.openjdk.org/jdk/pull/24462

From vlivanov at openjdk.org  Mon Apr  7 23:32:06 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 7 Apr 2025 23:32:06 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 7 Apr 2025 23:03:03 GMT, Vladimir Ivanov  wrote:

>> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
>> 
>> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
>> 
>> The patch consists of the following parts:
>>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
>> 
>> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
>> 
>> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
>> 
>> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
>> 
>> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
>> 
>> Thanks!
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   features_string -> cpu_info_string

In addition to addressing review feedback, there are 2 updates:
  * SVML: I overlooked that 64-bit vectors are covered by original implementation; fixed now;
  * JVM:  `features_string` to `cpu_info_string` renaming  uniformly across all platforms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24462#issuecomment-2784850623

From smarks at openjdk.org  Mon Apr  7 23:43:29 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 7 Apr 2025 23:43:29 GMT
Subject: RFR: 8351740: Clean up some code around initialization of encoding
 properties [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 7 Apr 2025 17:15:34 GMT, Naoto Sato  wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment from file.encoding to native.encoding
>
> src/java.base/share/native/libjava/System.c line 153:
> 
>> 151:     /*
>> 152:      * Since sun_jnu_encoding is now hard-coded to UTF-8 on Mac, we don't
>> 153:      * want to use it to overwrite file.encoding
> 
> This `file.encoding` can also be renamed. Should have been done with JEP 400

Updated, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24463#discussion_r2032151273

From smarks at openjdk.org  Mon Apr  7 23:43:29 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 7 Apr 2025 23:43:29 GMT
Subject: RFR: 8351740: Clean up some code around initialization of encoding
 properties [v2]
In-Reply-To: 
References: 
Message-ID: 

> Some of the code that creates various encoding properties at JVM initialization time, such as file.encoding and native.encoding, could use some cleaning up. Cleanup is fairly minimal and should be mostly behavior-preserving. Changes include the following:
> 
> * In the java_props.h and java_props_md.c files, add documentation and asserts that the sprops.encoding and sprops.sun_jnu_encoding members are always set to non-NULL by the platform-specific code.
> 
> * In SystemProps.java, remove a null check that is now extraneous based on the above assertion.
> 
> * In SystemProps.java, rearrange logic (with no behavior change) around handling of the "COMPAT" value for the file.encoding property.
> 
> * In SystemProps.Raw, rename the platform properties array index from _file_encoding_NDX to _native_encoding_NDX.
> 
> * In SystemProps.Raw.cmdProperties(), adjust the HashMap size computation. This should actually avoid resizing of the HashMap (unlike the earlier code).
> 
> * Adjust various comments in several places for clarity and correctness.

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Fix comment from file.encoding to native.encoding

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24463/files
  - new: https://git.openjdk.org/jdk/pull/24463/files/f5ba54f9..e8f3d35e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24463&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24463&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24463.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24463/head:pull/24463

PR: https://git.openjdk.org/jdk/pull/24463

From jpai at openjdk.org  Tue Apr  8 00:38:18 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Apr 2025 00:38:18 GMT
Subject: RFR: 8353787: Increased number of SHA-384-Digest
 java.util.jar.Attributes$Name instances leading to higher memory footprint
In-Reply-To: 
References: 
Message-ID: <887z3437qFFcUQj0euLTGyu1jcOMu9CYA5B_Jm9sEp4=.711799ca-2294-4143-9330-a1fabc80fbd2@github.com>

On Mon, 7 Apr 2025 06:34:11 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this change which proposes to address the increase in memory footprint of an application that uses signed JAR files, signed with `SHA-384` digest algorithm? This addresses https://bugs.openjdk.org/browse/JDK-8353787.
> 
> As noted in that issue and the linked mailing list discussion, it has been noticed that when JARs signed with `SHA-384` digest algorithm (which is the default since Java 19) are loaded, the number of `java.util.Attributes$Name` instances held in memory increase, leading to an increase in the memory footprint of the application.
> 
> The `Attributes` class has an internal cache which is meant to store `Name` instances of some well-known manifest attributes. It already has the `Name` instances for `SHA1-Digest` and `SHA-256-Digest` manifest attributes cached, but is missing an entry for `SHA-384-Digest`. The commit in this PR adds `SHA-384-Digest` to that cache.
> 
> Given the nature of this change, no new jtreg test has been introduced and existing tests in tier1, tier2 and tier3 continue to pass with this change. I've manually verified that this change does reduce the memory footprint of an application which has signed JARs with `SHA-384` digest algorithm  (details in a comment of this PR).

Thank you Sean and Lance for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24475#issuecomment-2784935034

From jpai at openjdk.org  Tue Apr  8 00:38:18 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Apr 2025 00:38:18 GMT
Subject: Integrated: 8353787: Increased number of SHA-384-Digest
 java.util.jar.Attributes$Name instances leading to higher memory footprint
In-Reply-To: 
References: 
Message-ID: 

On Mon, 7 Apr 2025 06:34:11 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this change which proposes to address the increase in memory footprint of an application that uses signed JAR files, signed with `SHA-384` digest algorithm? This addresses https://bugs.openjdk.org/browse/JDK-8353787.
> 
> As noted in that issue and the linked mailing list discussion, it has been noticed that when JARs signed with `SHA-384` digest algorithm (which is the default since Java 19) are loaded, the number of `java.util.Attributes$Name` instances held in memory increase, leading to an increase in the memory footprint of the application.
> 
> The `Attributes` class has an internal cache which is meant to store `Name` instances of some well-known manifest attributes. It already has the `Name` instances for `SHA1-Digest` and `SHA-256-Digest` manifest attributes cached, but is missing an entry for `SHA-384-Digest`. The commit in this PR adds `SHA-384-Digest` to that cache.
> 
> Given the nature of this change, no new jtreg test has been introduced and existing tests in tier1, tier2 and tier3 continue to pass with this change. I've manually verified that this change does reduce the memory footprint of an application which has signed JARs with `SHA-384` digest algorithm  (details in a comment of this PR).

This pull request has now been integrated.

Changeset: b64cdc28
Author:    Jaikiran Pai 
URL:       https://git.openjdk.org/jdk/commit/b64cdc28132c889ca8e21dc9534590ba2a778bcd
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8353787: Increased number of SHA-384-Digest java.util.jar.Attributes$Name instances leading to higher memory footprint

Reviewed-by: mullan, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/24475

From swen at openjdk.org  Tue Apr  8 01:11:17 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 8 Apr 2025 01:11:17 GMT
Subject: RFR: 8353741: Improve UUID.toString performance by using SIMD
 within a register instead of table lookup [v3]
In-Reply-To: 
References: 
 
Message-ID: <67VSpJlbozJVzcyNbhMl68QUmTTlQd2nV34W7Ofz2Ck=.1c974a89-e120-438e-b7e4-580de622a008@github.com>

On Sat, 5 Apr 2025 05:30:25 GMT, Shaojin Wen  wrote:

>> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD within a register) instead of table lookup. Eliminating the table lookup can also avoid the performance degradation problem when the cache misses.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify code

https://github.com/wenshao/jdk/tree/optim_uuid_to_string_202501_x2

I also made a version that does not use ByteArrayLittleEndian, but the performance drops by 5% to 10%. By printing the igv file through PrintIdealGraph, I found that the RangeCheck of array access is not eliminated.

[pr_22928_igv.zip](https://github.com/user-attachments/files/19640905/pr_22928_igv.zip)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22928#issuecomment-2784980276

From duke at openjdk.org  Tue Apr  8 05:14:23 2025
From: duke at openjdk.org (=?UTF-8?B?SmVhbi1Ob8OrbA==?= Rouvignac)
Date: Tue, 8 Apr 2025 05:14:23 GMT
Subject: RFR: 8352971: Increase maximum number of hold counts for
 ReentrantReadWriteLock [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 7 Apr 2025 13:55:27 GMT, Viktor Klang  wrote:

>> I'm breaking this change out as a separate improvement, since it will not be generally possible to adjust these limits on the j.u.c primitives since they might already use a backing `long` to pack in information which needs to be updated atomically (would require 128-bit atomics to widen them, and it still infeasible to change return types of pre-existing APIs).
>
> Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Make sure that the test fails in case of an InterruptedException
>  - Adding support for more than 65k readers and writers of ReentrantReadWriteLock

src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java line 1:

> 1: /*

@viktorklang-ora thank you so much for pushing this through!

There's a small nit: a co-worker noticed that this part of the javadoc is no longer true:

 * 
Implementation Notes

 *
 * 
This lock supports a maximum of 65535 recursive write locks
 * and 65535 read locks. Attempts to exceed these limits result in
* {@link Error} throws from locking methods.


Thanks again!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24261#discussion_r2032392894

From alanb at openjdk.org  Tue Apr  8 06:06:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 8 Apr 2025 06:06:28 GMT
Subject: Integrated: 8353267: jmod create finds the wrong set of packages when
 class file are in non-package location
In-Reply-To: <1ECZmIwkZ3iCpm_33bJxUO-GmFQwc0hqbwr9OQ2ljWo=.1cc1f217-6231-4ebf-a0aa-d8153b31e189@github.com>
References: <1ECZmIwkZ3iCpm_33bJxUO-GmFQwc0hqbwr9OQ2ljWo=.1cc1f217-6231-4ebf-a0aa-d8153b31e189@github.com>
Message-ID: 

On Tue, 1 Apr 2025 17:33:43 GMT, Alan Bateman  wrote:

> `jmod create` maps the contents of the module to a set of packages. This mapping derives illegal package names when class resources are located in non-package locations, e.g. in the META-INF tree. `jlink` also has an issue in this area and doesn't correctly determine if a resource is in a named package when the resource is class file in a non-package location.

This pull request has now been integrated.

Changeset: fb955bcb
Author:    Alan Bateman 
URL:       https://git.openjdk.org/jdk/commit/fb955bcb153b7008b45e9080c0817fcce7b5463e
Stats:     214 lines in 4 files changed: 180 ins; 6 del; 28 mod

8353267: jmod create finds the wrong set of packages when class file are in non-package location

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/24362

From jpai at openjdk.org  Tue Apr  8 06:10:31 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Apr 2025 06:10:31 GMT
Subject: RFR: 8066583: DeflaterInput/OutputStream and
 InflaterInput/OutputStream should explain responsibility for freeing resources
 [v10]
In-Reply-To: 
References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com>
 
Message-ID: <7Q8D1rJvoKgPzXvARMD7Dz6JsITU9CfTV9fYxO18M9A=.f278586b-bdf0-4216-9b00-5b21cccf05a9@github.com>

On Mon, 7 Apr 2025 09:05:36 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`.
>> 
>> The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes.
>> 
>> I'll draft a CSR once we agree on the proposed text.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   "a" instead of "the"

Thank you everyone for the inputs and help on taking this to completion. The CSR has been approved. I'll go ahead and integrate this now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23655#issuecomment-2785327642

From jpai at openjdk.org  Tue Apr  8 06:10:31 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Apr 2025 06:10:31 GMT
Subject: Integrated: 8066583: DeflaterInput/OutputStream and
 InflaterInput/OutputStream should explain responsibility for freeing resources
In-Reply-To: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com>
References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com>
Message-ID: <2StpJgFYC4FCVnpJWjmgOZHVc02buz0RsRKhEpMucbQ=.813758d9-9cd5-4743-9159-41c0dfa76f15@github.com>

On Sun, 16 Feb 2025 11:44:23 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`.
> 
> The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes.
> 
> I'll draft a CSR once we agree on the proposed text.

This pull request has now been integrated.

Changeset: 9844c1c5
Author:    Jaikiran Pai 
URL:       https://git.openjdk.org/jdk/commit/9844c1c52b9b7b6959d4e5cc626495c83f4aa9d4
Stats:     344 lines in 6 files changed: 328 ins; 0 del; 16 mod

8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources

Reviewed-by: liach, alanb, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/23655

From alanb at openjdk.org  Tue Apr  8 06:44:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 8 Apr 2025 06:44:15 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 7 Apr 2025 18:40:35 GMT, Roger Riggs  wrote:

>> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
>> 
>> @Deprecated(forRemoval = true, since="25")
>> Is added to each class and the existing @apiNote is converted to @deprected
>
> 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:
> 
>  - Revert "Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions."
>    SecureClassLoader.getPermissions and URLClassLoader.getPermissions are not marked as Deprecated.
>  - Merge branch 'master' into 8353641-deprecate-premission-classes
>  - Missing suppresswarnings
>  - Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions.
>    Remove dead code from ForkJoinPool.
>    Add @SuppressWarnings("remove")
>  - Remove unnecessary SuppressWarnings and correct Deprecated annotation style
>  - Update copyright in WindowsFileCopy
>  - Remove unused import of LinkPermission
>  - Updated style of @Deprecated to match most existing @Deprecated annotations
>    `since` comes before `forRemoval`
>    No spaces around `=`
>  - Add SuppressWarnings to a Windows source missed earlier.
>  - 8353641: Deprecate core library permission classes for removal
>    
>    Now that the Security Manager is permanently disabled, the following permission classes
>    in the core libraries area can be deprecated for removal as they are no longer useful:
>    FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission,
>    RuntimePermission, and SerializablePermission
>    
>    @Deprecated(forRemoval = true, since="25")
>    Is added to each class and the existing @apiNote is converted to @deprected

src/java.base/share/classes/jdk/internal/access/JavaIOFilePermissionAccess.java line 49:

> 47:      */
> 48:     @SuppressWarnings("removal")
> 49:     FilePermission newPermUsingAltPath(FilePermission input);

I assume JavaIOFilePermissionAccess can be removed, nothing should be using this now.

src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java line 443:

> 441:     @SuppressWarnings("removal")
> 442:     private void defineTransletClasses()
> 443:         throws TransformerConfigurationException {

In passing, the PermissionCollection used to construct the PD here is no longer needed. If this is cleaned up then the SW wouldn't be needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2032494012
PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2032493150

From fyang at openjdk.org  Tue Apr  8 07:15:20 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 8 Apr 2025 07:15:20 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L
In-Reply-To: 
References: 
Message-ID: 

On Mon, 7 Apr 2025 14:23:52 GMT, Hamlin Li  wrote:

> Hi,
> Can you help to review this patch?
> On riscv, CMoveI/L already were implemented, but there are some gap:
> 1. CMoveI/L does not support comparison with float/double, corresponding tests are not turn on either.
> 2. Some optimization of C2 is not turned on, e.g. `Phi -> CMove -> min_max`.
> 3. lack of some corresponding performance tests.
> 
> Also there are some issue with current Zicond:
> 1. UseZicond is turned on automatically by hwprobe, but jmh tests show that it's not always bring benefit, in some situation it even brings regression, the reason is the generated code by Zicond is much larger than branch version, in particular when it's in a loop and unrolled.
> 
> This patch on riscv is to:
> 1. add CMoveI/L comparing float/double, and corresponding tests,
> 2. enable more C2 optimization,
> 3. add more benchmark tests,
> 4. turn off UseZicond by default.
> 
> Thanks!

Hi, @Hamlin-Li , Thanks for looking at this part. I once created JBS https://bugs.openjdk.org/browse/JDK-8346786 about `ConditionalMoveLimit` on RISC-V. I have two questions after a cursory look.

src/hotspot/cpu/riscv/vm_version_riscv.cpp line 257:

> 255:   if (ConditionalMoveLimit > 0) {
> 256:     FLAG_SET_DEFAULT(ConditionalMoveLimit, 0);
> 257:   }

Maybe we should check `UseZicond` and only enable `UseCMoveUnconditionally` & `ConditionalMoveLimit` conditionally? I don't see how enabling CMove will bring us performance benefit without `Zicond`. It's done with conditional branches in CPU backend.

src/hotspot/cpu/riscv/vm_version_riscv.cpp line 461:

> 459:     FLAG_SET_DEFAULT(UseZicond, false);
> 460:     warning("UseZicond is turned off automatically. Turn it on with -XX:+UseZicond explicitly.");
> 461:   }

Does this mean `UseZicond` could not be enabled on the command line? And I witnessed quite some warning when doing a native build. If `UseZicond` causes regression for some cases, is it more reasonable to not auto-enable it through hwprobe [1]? Or only enable it for debug builds like https://github.com/openjdk/jdk/pull/24478 does?

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp#L228

-------------

PR Review: https://git.openjdk.org/jdk/pull/24490#pullrequestreview-2748525865
PR Review Comment: https://git.openjdk.org/jdk/pull/24490#discussion_r2032530242
PR Review Comment: https://git.openjdk.org/jdk/pull/24490#discussion_r2032292830

From dnawab at outlook.com  Tue Apr  8 08:24:32 2025
From: dnawab at outlook.com (Danish Nawab)
Date: Tue, 8 Apr 2025 08:24:32 +0000
Subject: Usage feedback: jnativescan
In-Reply-To: <98b89a42-7ac9-457e-bfbb-6eeb71835add@oracle.com>
References: 
 <98b89a42-7ac9-457e-bfbb-6eeb71835add@oracle.com>
Message-ID: 

Thanks for your analysis and explanation.

I took the liberty to propose a PR for JDK-8353840:
https://github.com/openjdk/jdk/pull/24499

I would really appreciate a review on this.


________________________________
From: Jorn Vernee 
Sent: Monday, April 7, 2025 3:46 AM
To: Danish Nawab ; core-libs-dev at openjdk.org 
Subject: Re: Usage feedback: jnativescan


Hello,


I had a look here, and can reproduce the error.


jnativescan does have handling for Multi-Release jars. By default it uses the current JDK version, which in your case would be 24. An exact version can be specified using --release. The issue in this case is that the error originates from the class file reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException, which does not have a class file entry in the META-INF/versions directory. There is one for the enclosing class reactor.core.publisher.CallSiteSupplierFactory, but not for this nested class. jnativescan doesn't try to determine whether a class file is used, it just scans all the class files in the jar file that belong to a particular runtime version, so in this case, it doesn't see that the TracingException class is not actually being used.


I think your idea of emitting a warning instead of an error is probably the right one. We won't be able to determine whether a method being referenced is restricted or not, since you need the class file to be able to look at the annotations, but if the class can not be loaded on the particular runtime version, then even if the method was restricted, it could never be called any way.


Thank you for submitting this useful piece of feedback! I've filed: https://bugs.openjdk.org/browse/JDK-8353840


Jorn


On 4-4-2025 18:58, Danish Nawab wrote:
jnativescan terminates when ran on a JAR with a missing class.
Example:

```
jnativescan --class-path reactor-core-3.7.4.jar

ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String
CAUSED BY: System class can not be found: sun.misc.JavaLangAccess
```

(above jar downloaded from [1])

The offending class seems to refer to a now unavailable sun.misc.JavaLangAccess but still handles this error scenario silently [2]

Because jnativescan terminates early, I can't say whether or not this library uses native/restricted features. Perhaps it would be better if instead of terminating, jnativescan continued the analysis after warning about the missing class.

Also, the above JAR seems to be a Multi-Release Jar, where the Java 11+ version of the code does not even refer sun.misc.JavaLangAccess [3].
Should jnativescan have special handling for Multi-Release JARs by analysing the version that would be applicable for the current JDK?

Versions:
```
java --version
openjdk 24 2025-03-18
OpenJDK Runtime Environment (build 24+36-3646)
OpenJDK 64-Bit Server VM (build 24+36-3646, mixed mode, sharing)

jnativescan --version
24
```

Overall, jnativescan is extremely helpful in finding the dependencies using native/restricted features.

[1] https://repo1.maven.org/maven2/io/projectreactor/reactor-core/3.7.4/reactor-core-3.7.4.jar
[2] https://github.com/reactor/reactor-core/blob/7dee739/reactor-core/src/main/java/reactor/core/publisher/CallSiteSupplierFactory.java#L56-L64
[3] https://github.com/reactor/reactor-core/blob/0b93178/reactor-core/src/main/java11/reactor/core/publisher/CallSiteSupplierFactory.java

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Tue Apr  8 08:26:23 2025
From: duke at openjdk.org (Danish Nawab)
Date: Tue, 8 Apr 2025 08:26:23 GMT
Subject: RFR: 8353840: jnativescan should not throw error for missing system
 classes
Message-ID: 

## Description

https://bugs.openjdk.org/browse/JDK-8353840 

### Existing behavior
Log the error message and terminate in case of missing system class

### New behavior
Still log the error message about the missing system class, but continue the analysis

## Design choices

Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis

### Alternatives considered

- Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`.
    - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception 
- Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver`
    - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful

### stdout vs stderr 

One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed.

## Testing

The existing test `TestMissingSystemClass#testSingleJarClassPath` has been adapted to test for successful execution, as well as verify the stdout output. 
I considered briefly to update the test setup in a way that we see some restricted methods on the stdout instead of just ``, but it was unclear if that would really add any additional value since the main purpose of this test is just to ascertain the missing system class (with successful execution from now onward).

-------------

Commit messages:
 - 8353840: jnativescan should not throw error for missing system classes

Changes: https://git.openjdk.org/jdk/pull/24499/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24499&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353840
  Stats: 17 lines in 4 files changed: 6 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/24499.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24499/head:pull/24499

PR: https://git.openjdk.org/jdk/pull/24499

From hannesw at openjdk.org  Tue Apr  8 09:02:25 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 8 Apr 2025 09:02:25 GMT
Subject: RFR: 8254622: Hide superclasses from conditionally exported
 packages [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review an enhancement to treat classes and interfaces that are not included and not unconditionally exported as hidden. This means they do not show up in the generated documentation even if they are implemented or extended by a documented type. 
> 
> This change makes the `@hidden` JavaDoc tag unnecessary in two internal base classes that previously used it, `jdk.internal.vm.vector.VectorSupport` and `jdk.internal.event.Event`. The generated documentation is unchanged.
> 
> The change also adds support for the `@hidden` JavaDoc tag in interfaces, which was previously missing, and adds coverage to `TestHiddenTag.java`.

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback: add Utils.isVisible(TypeElement) method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24446/files
  - new: https://git.openjdk.org/jdk/pull/24446/files/6e83725e..682e1ebe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24446&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24446&range=00-01

  Stats: 61 lines in 10 files changed: 26 ins; 14 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/24446.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24446/head:pull/24446

PR: https://git.openjdk.org/jdk/pull/24446

From hannesw at openjdk.org  Tue Apr  8 09:07:27 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 8 Apr 2025 09:07:27 GMT
Subject: RFR: 8254622: Hide superclasses from conditionally exported
 packages [v2]
In-Reply-To: <3TeN5yxeLsHqA9fv2BBz4ErEn0y8zXfHuct9uvc6cak=.19223c83-732e-4ead-82fb-b5f0bb422e02@github.com>
References: 
 <3TeN5yxeLsHqA9fv2BBz4ErEn0y8zXfHuct9uvc6cak=.19223c83-732e-4ead-82fb-b5f0bb422e02@github.com>
Message-ID: 

On Sat, 5 Apr 2025 00:35:35 GMT, Chen Liang  wrote:

>> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback: add Utils.isVisible(TypeElement) method
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java line 165:
> 
>> 163:                     for (TypeMirror type : interfaces) {
>> 164:                         TypeElement tDoc = utils.asTypeElement(type);
>> 165:                         if (!(utils.isPublic(tDoc) || utils.isLinkable(tDoc)) || utils.isHidden(tDoc)) {
> 
> This `(!isPublicOrProtected && !isLinkable) || isHidden` trio appears a few times. The conditions are negated and wrapped in parentheses so it is easily confusing on the web; can we extract this check into a new utils method?

That's a very good suggestion. In 682e1eb I added a new `Utils.isVisible(TypeElement)` method which returns true if the argument is not hidden and either public or (externally or internally) linkable. 

I found a few places that only had the public/linkable part but should also have the hidden check (`LinkTaglet` and `AbstractTreeWriter`). I updated these places to use the new method and enhanced `TestHiddenTag` to cover these cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24446#discussion_r2032742066

From jpai at openjdk.org  Tue Apr  8 09:25:13 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Apr 2025 09:25:13 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance [v2]
In-Reply-To: <8UqLlWwRDd27THNn3oXl2n3LNc6UODiKoPYJa7p3S_0=.c38e4afe-2823-4ffe-9557-01295137930f@github.com>
References: 
 <8UqLlWwRDd27THNn3oXl2n3LNc6UODiKoPYJa7p3S_0=.c38e4afe-2823-4ffe-9557-01295137930f@github.com>
Message-ID: 

On Tue, 1 Apr 2025 00:59:57 GMT, Jason Zaugg  wrote:

>> 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance
>
> Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8352642: Also pass zipinfo-time to the alternative newFileSystem call

src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 581:

> 579:                 // Less common case is possible if the file manager was not initialized in JavacTask,
> 580:                 // or if non "*.jar" files are on the classpath. At the time of writing, both `javac -cp a.zip`
> 581:                 // and `javac -cp x.JAR` file would hit this branch which may warrant investigation.

Hello Jason, do we need that second sentence to be added as a code comment? I feel it creates confusion on what's expected to be done. Perhaps just add that first sentence and remove the second?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24176#discussion_r2032773634

From jpai at openjdk.org  Tue Apr  8 09:25:13 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Apr 2025 09:25:13 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance [v2]
In-Reply-To: 
References: 
 <8UqLlWwRDd27THNn3oXl2n3LNc6UODiKoPYJa7p3S_0=.c38e4afe-2823-4ffe-9557-01295137930f@github.com>
 
Message-ID: <4YJv_Epumc0H6kV6HXamzgbBGQ4rqsgLF6_x3Zgs1OU=.4ae39a90-887e-4c6b-a95c-d29727848336@github.com>

On Tue, 8 Apr 2025 09:21:50 GMT, Jaikiran Pai  wrote:

>> Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8352642: Also pass zipinfo-time to the alternative newFileSystem call
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 581:
> 
>> 579:                 // Less common case is possible if the file manager was not initialized in JavacTask,
>> 580:                 // or if non "*.jar" files are on the classpath. At the time of writing, both `javac -cp a.zip`
>> 581:                 // and `javac -cp x.JAR` file would hit this branch which may warrant investigation.
> 
> Hello Jason, do we need that second sentence to be added as a code comment? I feel it creates confusion on what's expected to be done. Perhaps just add that first sentence and remove the second?

Could you also update the copyright year on this file from 2024 to 2025?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24176#discussion_r2032774982

From vklang at openjdk.org  Tue Apr  8 09:41:55 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 8 Apr 2025 09:41:55 GMT
Subject: RFR: 8354016: Update ReentrantReadWriteLock documentation to reflect
 its new max capacity
Message-ID: 

Updating the ReentrantReadWriteLock documentation

-------------

Commit messages:
 - Adding links
 - Updates ReentrantReadWriteLock to state the new hold capacities

Changes: https://git.openjdk.org/jdk/pull/24502/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24502&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354016
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24502.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24502/head:pull/24502

PR: https://git.openjdk.org/jdk/pull/24502

From rehn at openjdk.org  Tue Apr  8 09:44:23 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 8 Apr 2025 09:44:23 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v3]
In-Reply-To: <5sujqD7L_cmLUyDwYb4PhgOlEeiFwlkAV7RJoVMFTrM=.223437cd-bbb2-4ef3-a6fe-b13ce402e14b@github.com>
References: 
 <5sujqD7L_cmLUyDwYb4PhgOlEeiFwlkAV7RJoVMFTrM=.223437cd-bbb2-4ef3-a6fe-b13ce402e14b@github.com>
Message-ID: 

On Mon, 31 Mar 2025 10:45:54 GMT, Robbin Ehn  wrote:

>> Hi, for you to consider.
>> 
>> These tests constantly fails in qemu-user.
>> Either the require host to be same arch explicit or implicit (sysroot).
>> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'" for SA tests.
>> 
>> From bug:
>>> qemu-user/rv64 sets uarch to "qemu" in /proc/cpuinfo (qemu-system do not do that).
>>> We add this uarch to CPU feature string.
>>> This means we can use jtreg 'require' with cpu string to filter out tests in qemu-user.
>> 
>> Relevant qemu code:
>> https://github.com/qemu/qemu/blob/170825d14d88a1ce7fae98d5a928480f2f329b22/linux-user/riscv/target_proc.h#L29
>> 
>> Relevant hotspot code:
>> https://github.com/openjdk/jdk/blob/fa0b18bfde38ee2ffbab33a9eaac547fe8aa3c7c/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L250
>> 
>> Tested that the require only filters out tests in qemu+riscv64.
>> 
>> Thanks!
>> 
>> /Robbin
>
> Robbin Ehn 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' into qemu-user-issues
>  - Revert
>  - Merge branch 'master' into qemu-user-issues
>  - Merge branch 'master' into qemu-user-issues
>  - more
>  - more
>  - native or very long

Any takers?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2785851072

From vklang at openjdk.org  Tue Apr  8 10:11:45 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 8 Apr 2025 10:11:45 GMT
Subject: RFR: 8354016: Update ReentrantReadWriteLock documentation to
 reflect its new max capacity [v2]
In-Reply-To: 
References: 
Message-ID: 

> Updating the ReentrantReadWriteLock documentation

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
  
  Removing space

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24502/files
  - new: https://git.openjdk.org/jdk/pull/24502/files/c7b8d712..80e4d8a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24502&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24502&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24502.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24502/head:pull/24502

PR: https://git.openjdk.org/jdk/pull/24502

From vklang at openjdk.org  Tue Apr  8 10:11:45 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 8 Apr 2025 10:11:45 GMT
Subject: RFR: 8354016: Update ReentrantReadWriteLock documentation to
 reflect its new max capacity [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 8 Apr 2025 10:08:26 GMT, Viktor Klang  wrote:

>> Updating the ReentrantReadWriteLock documentation
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
>   
>   Removing space

src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java line 211:

> 209:  *
> 210:  * 
This lock supports a maximum of {@link Integer#MAX_VALUE} recursive write locks
> 211:  * and {@link Integer#MAX_VALUE } read locks. Attempts to exceed these limits result in

Suggestion:

 * and {@link Integer#MAX_VALUE} read locks. Attempts to exceed these limits result in

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24502#discussion_r2032856765

From alanb at openjdk.org  Tue Apr  8 10:21:26 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 8 Apr 2025 10:21:26 GMT
Subject: RFR: 8354016: Update ReentrantReadWriteLock documentation to
 reflect its new max capacity [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 8 Apr 2025 10:11:45 GMT, Viktor Klang  wrote:

>> Updating the ReentrantReadWriteLock documentation
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
>   
>   Removing space

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24502#pullrequestreview-2749453616

From mli at openjdk.org  Tue Apr  8 10:32:20 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 8 Apr 2025 10:32:20 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 8 Apr 2025 07:07:12 GMT, Fei Yang  wrote:

> Maybe we should check UseZicond and only enable UseCMoveUnconditionally & ConditionalMoveLimit conditionally?

Not sure what do you mean here.

> I don't see how enabling CMove will bring us any performance benefit without Zicond. It's done with conditional branches in CPU backend as well.

I add the performance result in desc.
There are 2 optimization scenarios, one is cmove itself, another is when cmove can be transform to a min/max in some condition.

> src/hotspot/cpu/riscv/vm_version_riscv.cpp line 461:
> 
>> 459:     FLAG_SET_DEFAULT(UseZicond, false);
>> 460:     warning("UseZicond is turned off automatically. Turn it on with -XX:+UseZicond explicitly.");
>> 461:   }
> 
> Does this mean `UseZicond` could not be enabled on the command line? And I witnessed quite some warning when doing a native build. If `UseZicond` causes regression for some cases, is it more reasonable to not auto-enable it through hwprobe [1]? Or only enable it for debug builds like https://github.com/openjdk/jdk/pull/24478 does?
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp#L228

This is to not enable Zicond automatically, but user can still turn it on manually if they want to try or make sure it bring benefit on the specific hardware.
Currently it's based on bananapi result, so maybe  in the future we should adjust the default value of UseZicond.
I'm fine with either default value.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24490#discussion_r2032893506
PR Review Comment: https://git.openjdk.org/jdk/pull/24490#discussion_r2032893370

From duke at openjdk.org  Tue Apr  8 11:07:11 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 8 Apr 2025 11:07:11 GMT
Subject: RFR: 8353683: [REDO] j.u.l.Handler classes create deadlock risk via
 synchronized publish() method
Message-ID: <2l5AHWU2u5_pJSlTHuCbW4NXM6Rzdq1vjvvoca0wKC0=.0a9cfc62-70dc-498e-816e-469ffbbca9ce@github.com>

8353683: j.u.l.Handler classes create deadlock risk via synchronized publish() method.

1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
2. Add explanatory comments to various affected methods.
3. Add a test to ensure deadlocks no longer occur.

Note that this change does not address issue in MemoryHandler (see JDK-8349208).

-------------

Commit messages:
 - Fix JavaDoc error.
 - Restore original patch.

Changes: https://git.openjdk.org/jdk/pull/24504/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24504&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353683
  Stats: 453 lines in 8 files changed: 430 ins; 8 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/24504.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24504/head:pull/24504

PR: https://git.openjdk.org/jdk/pull/24504

From duke at openjdk.org  Tue Apr  8 11:07:11 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 8 Apr 2025 11:07:11 GMT
Subject: RFR: 8353683: [REDO] j.u.l.Handler classes create deadlock risk
 via synchronized publish() method
In-Reply-To: <2l5AHWU2u5_pJSlTHuCbW4NXM6Rzdq1vjvvoca0wKC0=.0a9cfc62-70dc-498e-816e-469ffbbca9ce@github.com>
References: <2l5AHWU2u5_pJSlTHuCbW4NXM6Rzdq1vjvvoca0wKC0=.0a9cfc62-70dc-498e-816e-469ffbbca9ce@github.com>
Message-ID: 

On Tue, 8 Apr 2025 11:00:27 GMT, David Beaumont  wrote:

> 8353683: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

This is a redo of https://github.com/openjdk/jdk/pull/23491 with a tiny additional edit to remove an unwanted `
` element in the public JavaDoc (see https://github.com/openjdk/jdk/pull/24504/commits/772a03e0ca08da9412b85ceb8de5adf4fb52d2ac ).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24504#issuecomment-2786062041

From pminborg at openjdk.org  Tue Apr  8 11:23:36 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 8 Apr 2025 11:23:36 GMT
Subject: Withdrawn: 8350334: Add final keywords to FFM methods
In-Reply-To: <6DDqOOkbNVUXgUWn9flY41lfcWIWVOgvBrgxa5njpSg=.b9893567-2543-49c8-bc3f-c3b88e27bcab@github.com>
References: <6DDqOOkbNVUXgUWn9flY41lfcWIWVOgvBrgxa5njpSg=.b9893567-2543-49c8-bc3f-c3b88e27bcab@github.com>
Message-ID: <-o6fOdl46FGchm1AXd5TlGQ0DGgD2U5TKOuduaTcS_U=.fd041d5a-e365-4f3d-aa91-b28306cf0fbc@github.com>

On Wed, 19 Feb 2025 14:23:04 GMT, Per Minborg  wrote:

> This PR proposes to add the `final` keyword to some classes and methods in order to assist compiler devirtualization (e.g. in Graal native image).
> 
> Passes `make test TEST=jdk_foreign`

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/23696

From pminborg at openjdk.org  Tue Apr  8 11:33:54 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 8 Apr 2025 11:33:54 GMT
Subject: RFR: 8348556: Inlining fails earlier for
 MemorySegment::reinterpret [v6]
In-Reply-To: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
References: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
Message-ID: <6wb-C25gjMYaQZXn2BFAQ2okygXAiHNxciy-zmDsy9M=.7555f6bb-2112-42d8-87ef-4ab63fab6d62@github.com>

> This PR proposes to add some `@ForceInline` annotations in the `Module` class in order to assist inlining of FFM var/method handles.
> 
> There are also some changes in other classes (notably `j.l.Object`) which, if implemented, can take us four additional levels of inlining. However, there is a tradeoff with adding `@ForceInline` and just trying to get as deep as possible for a specific use case is probably not the best idea. 
> 
> So, we should discuss which of the proposed changes (if any), we'd like to integrate.
> 
> Tested and passed tier1-3

Per Minborg 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 nine additional commits since the last revision:

 - Revert copyright year
 - Revert changes to Object
 - Merge branch 'master' into module-force-inline
 - Add more @ForceInline and a benchmark
 - Remove reformatting
 - Remove file
 - Revert change
 - Rename method and variable
 - Add @ForceInline annotations and restructure some methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23460/files
  - new: https://git.openjdk.org/jdk/pull/23460/files/7a2f7f89..401d9d4f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23460&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23460&range=04-05

  Stats: 212749 lines in 4960 files changed: 98853 ins; 86637 del; 27259 mod
  Patch: https://git.openjdk.org/jdk/pull/23460.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23460/head:pull/23460

PR: https://git.openjdk.org/jdk/pull/23460

From tpushkin at openjdk.org  Tue Apr  8 11:36:13 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 8 Apr 2025 11:36:13 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v4]
In-Reply-To: 
References: 
 <_jUyfQOHTQHeuKp72nHVOjSJJZtmjx-6ViBd9qi-IpA=.06a4213b-7834-4eda-b50f-4d362bbb761c@github.com>
 
Message-ID: 

On Mon, 7 Apr 2025 16:00:27 GMT, Ioi Lam  wrote:

>> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Don't use URLClassPath
>
> src/hotspot/share/cds/classListParser.cpp line 534:
> 
>> 532:   GrowableArray specified_interfaces = get_specified_interfaces();
>> 533: 
>> 534:   const char* source_path = ClassLoader::uri_to_path(_source);
> 
> Is `ClassLoader::uri_to_path` necessary? I think `_source` is already a file path.

`_source` is a URL with `file:`removed from the beginning of it, so yes, this is necessary.

For example, if a class resides in a directory called "my dir" its `_source` will be "my%20dir" ? `uri_to_path` will replace "%20" with " ".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2032994904

From asotona at openjdk.org  Tue Apr  8 11:40:14 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 8 Apr 2025 11:40:14 GMT
Subject: RFR: 8347472: Correct Attribute traversal and writing for Code
 attributes
In-Reply-To: 
References: 
Message-ID: 

On Fri, 7 Feb 2025 19:25:04 GMT, Chen Liang  wrote:

> Make UnknownAttribute and CustomAttribute delivered in code traversal, and make sure stack maps update the label references after a code transform when it is reused. Other code-bound attributes are not updated as they cannot be supplied to a CodeBuilder.
> 
> Tested the 2 cases in the new AttributesInCodeTest fails on earlier JDKs.
> 
> Testing: JDK tier 1-3 ongoing

It is nice to see these leftovers fixed, thanks.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23521#pullrequestreview-2749662182

From pminborg at openjdk.org  Tue Apr  8 11:44:23 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 8 Apr 2025 11:44:23 GMT
Subject: RFR: 8348556: Inlining fails earlier for
 MemorySegment::reinterpret [v6]
In-Reply-To: <6wb-C25gjMYaQZXn2BFAQ2okygXAiHNxciy-zmDsy9M=.7555f6bb-2112-42d8-87ef-4ab63fab6d62@github.com>
References: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
 <6wb-C25gjMYaQZXn2BFAQ2okygXAiHNxciy-zmDsy9M=.7555f6bb-2112-42d8-87ef-4ab63fab6d62@github.com>
Message-ID: 

On Tue, 8 Apr 2025 11:33:54 GMT, Per Minborg  wrote:

>> This PR proposes to add some `@ForceInline` annotations in the `Module` class in order to assist inlining of FFM var/method handles.
>> 
>> There are also some changes in other classes which, if implemented, can take us three additional levels of inlining. I drew a line there. There is a tradeoff with adding `@ForceInline` and just trying to get as deep as possible for a specific use case is probably not the best idea. 
>> 
>> I have opted not to inline the `j.l.Object` constructor in anticipation of broad impact. This currently sets the depth limit for this use case.
>> 
>> Tested and passed tier1-3
>
> Per Minborg 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 nine additional commits since the last revision:
> 
>  - Revert copyright year
>  - Revert changes to Object
>  - Merge branch 'master' into module-force-inline
>  - Add more @ForceInline and a benchmark
>  - Remove reformatting
>  - Remove file
>  - Revert change
>  - Rename method and variable
>  - Add @ForceInline annotations and restructure some methods

I have reverted the changes to `Object` and so, resetting the number of required reviewers

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23460#issuecomment-2786158848

From jvernee at openjdk.org  Tue Apr  8 11:44:58 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 8 Apr 2025 11:44:58 GMT
Subject: RFR: 8353917: jnativescan: Simplify ClassResolver
Message-ID: 

`jnativescan` uses the `ClassResolver` class to find both system classes, as well as application classes. In principle, a class resolver supports both iterating over all classes from that particular source, as well as looking up classes by name. However, the `ClassResolver` for system classes doesn't support iterating, and the lookup functionality for `ClassResolvers` from other sources is never used (only iterating).

This patch proposes to split the iterating functionality out of `ClassResolver`. Clients that were using this functionality will switch to using the iteration functionality that is available on `ClassFileSource` directly (whose classes were previously being wrapped in a `ClassResolver`). As a result of this latter change, we can now also let `NativeMethodFinder` operate on individual classes. We just iterate over all the class file sources in `JNativeScanTask`, and feed individual class models to `NativeMethodFinder`. I think this is a good conceptual simplification of `NativeMethodFinder`,

Since `ClassResolver` is now only used for system classes, I've removed it, leaving only its single implementation: `SystemClassResolver`.

Testing: running `langtools_jnativescan` test suite.

-------------

Commit messages:
 - bump copyright years
 - merge ClassResolver and SystemClassResolver
 - Simplify ClassResolver

Changes: https://git.openjdk.org/jdk/pull/24493/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24493&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353917
  Stats: 374 lines in 5 files changed: 150 ins; 191 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/24493.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24493/head:pull/24493

PR: https://git.openjdk.org/jdk/pull/24493

From jvernee at openjdk.org  Tue Apr  8 11:44:59 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 8 Apr 2025 11:44:59 GMT
Subject: RFR: 8353917: jnativescan: Simplify ClassResolver
In-Reply-To: 
References: 
Message-ID: 

On Mon, 7 Apr 2025 16:36:07 GMT, Jorn Vernee  wrote:

> `jnativescan` uses the `ClassResolver` class to find both system classes, as well as application classes. In principle, a class resolver supports both iterating over all classes from that particular source, as well as looking up classes by name. However, the `ClassResolver` for system classes doesn't support iterating, and the lookup functionality for `ClassResolvers` from other sources is never used (only iterating).
> 
> This patch proposes to split the iterating functionality out of `ClassResolver`. Clients that were using this functionality will switch to using the iteration functionality that is available on `ClassFileSource` directly (whose classes were previously being wrapped in a `ClassResolver`). As a result of this latter change, we can now also let `NativeMethodFinder` operate on individual classes. We just iterate over all the class file sources in `JNativeScanTask`, and feed individual class models to `NativeMethodFinder`. I think this is a good conceptual simplification of `NativeMethodFinder`,
> 
> Since `ClassResolver` is now only used for system classes, I've removed it, leaving only its single implementation: `SystemClassResolver`.
> 
> Testing: running `langtools_jnativescan` test suite.

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/ClassFileSource.java line 86:

> 84: 
> 85:     record ClassPathJar(Path path, Runtime.Version version) implements ClassFileSource {
> 86:         @Override

The runtime version was only being used by `ClassPathJar::classFiles`, so I've made it a property of `ClassPathjar` instead of a parameter to that method, which is not used by the other implementations.

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/NativeMethodFinder.java line 70:

> 68:     }
> 69: 
> 70:     private SortedSet findRestrictedMethodInvocations(MethodModel methodModel) {

Created this helper method to reduce the overall nesting of the `find` method.

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/SystemClassResolver.java line 41:

> 39: import java.util.*;
> 40: 
> 41: class SystemClassResolver implements AutoCloseable {

Code in this class is unchanged from the old implementation in `ClassFileResolver`, except that the class was moved to the top level, and some code moved around within the class to match existing style.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24493#discussion_r2031619068
PR Review Comment: https://git.openjdk.org/jdk/pull/24493#discussion_r2031620942
PR Review Comment: https://git.openjdk.org/jdk/pull/24493#discussion_r2031623738

From tpushkin at openjdk.org  Tue Apr  8 11:49:12 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 8 Apr 2025 11:49:12 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v4]
In-Reply-To: 
References: 
 <_jUyfQOHTQHeuKp72nHVOjSJJZtmjx-6ViBd9qi-IpA=.06a4213b-7834-4eda-b50f-4d362bbb761c@github.com>
 
Message-ID: 

On Mon, 7 Apr 2025 16:15:47 GMT, Ioi Lam  wrote:

>> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Don't use URLClassPath
>
> src/java.base/share/classes/jdk/internal/misc/CDS.java line 444:
> 
>> 442:         protected Class findClass(String name) throws ClassNotFoundException {
>> 443:             // Unregistered classes should be found in load(...), registered classes should be
>> 444:             // handeled by parent loaders
> 
> Hmm, I wonder how the reference to java.lang.Object is resolved in this case. When `CustomLoadee` is parsed, the ClassFileParser needs to resolve is super class, which should result into a call to `UnregisteredClassLoader::findClass()`.
> 
> 
>             "java/lang/Object id: 0",
>             "CustomLoadee id: 1 super: 0 source: .",

`UnregisteredClassLoader::loadClass` will be called, i.e. the default implementation from `ClassLoader::loadClass`, which will first try to delegate to parent. The delegation chain will reach the boot loader which will find `java.lang.Object` and thus `UnregisteredClassLoader::findClass()` won't be called.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2033015572

From jvernee at openjdk.org  Tue Apr  8 11:52:22 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 8 Apr 2025 11:52:22 GMT
Subject: RFR: 8353840: JNativeScan should not throw error for missing
 system classes
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 08:18:36 GMT, Danish Nawab  wrote:

> ## Description
> 
> https://bugs.openjdk.org/browse/JDK-8353840 
> 
> ### Existing behavior
> Log the error message and terminate in case of missing system class
> 
> 
> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?"
> 
> ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String
> CAUSED BY: System class can not be found: sun.misc.JavaLangAccess
> Exit code: 1
> 
> 
> ### New behavior
> Still log the error message about the missing system class, but continue the analysis
> 
> 
> $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" 
> 
>   
> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess
> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets
> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets
> Exit code: 0
> 
> 
> ## Design choices
> 
> Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis
> 
> ### Alternatives considered
> 
> - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`.
>     - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception 
> - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver`
>     - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful
> 
> ### stdout vs stderr 
> 
> One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed.
> 
> ## Testing
> 
> The existing test `TestMissingSystemClass#testSingleJarClassPath` has ...

I've updated the issue title to start with a capital letter.

Also, note that there was some other cleanup I wanted to do in this area first: https://github.com/openjdk/jdk/pull/24493 which will likely result in merge conflicts.

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/NativeMethodFinder.java line 91:

> 89:                              err.println("Error while processing method: " +
> 90:                                      MethodRef.ofModel(methodModel) + ": " + e.getMessage());
> 91:                          }

This catch block is per-method. It means that if the rest of the method contained references to restricted methods, we would not see them. The catch block should be moved to be just around the call to `isRestricted`, which can fail. Then we can record the error and keep iterating over the other instructions.

-------------

Changes requested by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24499#pullrequestreview-2749671492
PR Comment: https://git.openjdk.org/jdk/pull/24499#issuecomment-2786176663
PR Review Comment: https://git.openjdk.org/jdk/pull/24499#discussion_r2033007295

From jvernee at openjdk.org  Tue Apr  8 11:52:23 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 8 Apr 2025 11:52:23 GMT
Subject: RFR: 8353840: JNativeScan should not throw error for missing
 system classes
In-Reply-To: 
References: 
 
Message-ID: <-DMpfwwW1NzmpeOJuZJcgiv_Vhu-IvEMtt0tmvXLeJ0=.a8f6bedf-a293-4fef-b046-709ab46781f5@github.com>

On Tue, 8 Apr 2025 11:41:15 GMT, Jorn Vernee  wrote:

>> ## Description
>> 
>> https://bugs.openjdk.org/browse/JDK-8353840 
>> 
>> ### Existing behavior
>> Log the error message and terminate in case of missing system class
>> 
>> 
>> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?"
>> 
>> ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String
>> CAUSED BY: System class can not be found: sun.misc.JavaLangAccess
>> Exit code: 1
>> 
>> 
>> ### New behavior
>> Still log the error message about the missing system class, but continue the analysis
>> 
>> 
>> $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" 
>> 
>>   
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets
>> Exit code: 0
>> 
>> 
>> ## Design choices
>> 
>> Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis
>> 
>> ### Alternatives considered
>> 
>> - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`.
>>     - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception 
>> - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver`
>>     - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful
>> 
>> ### stdout vs stderr 
>> 
>> One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed....
>
> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/NativeMethodFinder.java line 91:
> 
>> 89:                              err.println("Error while processing method: " +
>> 90:                                      MethodRef.ofModel(methodModel) + ": " + e.getMessage());
>> 91:                          }
> 
> This catch block is per-method. It means that if the rest of the method contained references to restricted methods, we would not see them. The catch block should be moved to be just around the call to `isRestricted`, which can fail. Then we can record the error and keep iterating over the other instructions.

Also, instead of passing `err` down to this code, I think we should define an interface for `NativeMethodFinder` to log diagnostics instead. e.g. something like:


interface Diagnostics {
    void error(MethodRef context, JNativeScanFatalError error);
} 


`JNativeScanTask` can then define the implementation how it wants. The benefit of that is that we have more freedom to print the errors how we want. For instance, I think we should first collect all the errors, and de-duplicate error messages before printing them, so that if there are 10 references to the same system class, we only print the error message once, and we can print a header like: `Errors while processing classes: ...`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24499#discussion_r2033014629

From duke at openjdk.org  Tue Apr  8 11:58:15 2025
From: duke at openjdk.org (Danish Nawab)
Date: Tue, 8 Apr 2025 11:58:15 GMT
Subject: RFR: 8353840: JNativeScan should not throw error for missing
 system classes
In-Reply-To: <-DMpfwwW1NzmpeOJuZJcgiv_Vhu-IvEMtt0tmvXLeJ0=.a8f6bedf-a293-4fef-b046-709ab46781f5@github.com>
References: 
 
 <-DMpfwwW1NzmpeOJuZJcgiv_Vhu-IvEMtt0tmvXLeJ0=.a8f6bedf-a293-4fef-b046-709ab46781f5@github.com>
Message-ID: 

On Tue, 8 Apr 2025 11:45:49 GMT, Jorn Vernee  wrote:

>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/NativeMethodFinder.java line 91:
>> 
>>> 89:                              err.println("Error while processing method: " +
>>> 90:                                      MethodRef.ofModel(methodModel) + ": " + e.getMessage());
>>> 91:                          }
>> 
>> This catch block is per-method. It means that if the rest of the method contained references to restricted methods, we would not see them. The catch block should be moved to be just around the call to `isRestricted`, which can fail. Then we can record the error and keep iterating over the other instructions.
>
> Also, instead of passing `err` down to this code, I think we should define an interface for `NativeMethodFinder` to log diagnostics instead. e.g. something like:
> 
> 
> interface Diagnostics {
>     void error(MethodRef context, JNativeScanFatalError error);
> } 
> 
> 
> `JNativeScanTask` can then define the implementation how it wants. The benefit of that is that we have more freedom to print the errors how we want. For instance, I think we should first collect all the errors, and de-duplicate error messages before printing them, so that if there are 10 references to the same system class, we only print the error message once, and we can print a header like: `Errors while processing classes: ...`

> This catch block is per-method. It means that if the rest of the method contained references to restricted methods, we would not see them. The catch block should be moved to be just around the call to isRestricted, which can fail. Then we can record the error and keep iterating over the other instructions.

That makes a lot of sense. I will update it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24499#discussion_r2033030209

From duke at openjdk.org  Tue Apr  8 12:03:20 2025
From: duke at openjdk.org (Danish Nawab)
Date: Tue, 8 Apr 2025 12:03:20 GMT
Subject: RFR: 8353840: JNativeScan should not throw error for missing
 system classes
In-Reply-To: 
References: 
 
 <-DMpfwwW1NzmpeOJuZJcgiv_Vhu-IvEMtt0tmvXLeJ0=.a8f6bedf-a293-4fef-b046-709ab46781f5@github.com>
 
Message-ID: 

On Tue, 8 Apr 2025 11:55:58 GMT, Danish Nawab  wrote:

>> Also, instead of passing `err` down to this code, I think we should define an interface for `NativeMethodFinder` to log diagnostics instead. e.g. something like:
>> 
>> 
>> interface Diagnostics {
>>     void error(MethodRef context, JNativeScanFatalError error);
>> } 
>> 
>> 
>> `JNativeScanTask` can then define the implementation how it wants. The benefit of that is that we have more freedom to print the errors how we want. For instance, I think we should first collect all the errors, and de-duplicate error messages before printing them, so that if there are 10 references to the same system class, we only print the error message once, and we can print a header like: `Errors while processing classes: ...`
>
>> This catch block is per-method. It means that if the rest of the method contained references to restricted methods, we would not see them. The catch block should be moved to be just around the call to isRestricted, which can fail. Then we can record the error and keep iterating over the other instructions.
> 
> That makes a lot of sense. I will update it.

> Also, instead of passing err down to this code, I think we should define an interface for NativeMethodFinder to log diagnostics instead. e.g. something like:

This makes sense. I can update it, accordingly.
Regarding deduplication: this means we would need to buffer the errors and print them all at the end, which would require coordination between different layers, and we might need to mark `Diagnostics` as `Closable/AutoClosable`. 
Would it be ok for you, if the buffering/deduplication can be done a follow-up and for now we just change the termination behavior? Or do you see that as an essential component that should be included with this change?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24499#discussion_r2033037953

From tpushkin at openjdk.org  Tue Apr  8 12:09:59 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 8 Apr 2025 12:09:59 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v5]
In-Reply-To: 
References: 
Message-ID: <9nX8O13jWi7qORu4uO-ppDmlph2W2lH1VVIKFP3-Gt8=.46545db1-b218-497d-b4ef-546410b09b9b@github.com>

> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app.
> 
> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible.

Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary scoping

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24223/files
  - new: https://git.openjdk.org/jdk/pull/24223/files/16a2f951..dff524c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=03-04

  Stats: 19 lines in 1 file changed: 0 ins; 3 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/24223.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223

PR: https://git.openjdk.org/jdk/pull/24223

From luhenry at openjdk.org  Tue Apr  8 12:14:18 2025
From: luhenry at openjdk.org (Ludovic Henry)
Date: Tue, 8 Apr 2025 12:14:18 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L
In-Reply-To: 
References: 
Message-ID: <_8ulH1PIsfxxO_hBMK4kbMGF3eY1GQgsdUfk5bVVqCo=.d62134e2-b94f-4b9c-9b5f-f903441b7890@github.com>

On Mon, 7 Apr 2025 14:23:52 GMT, Hamlin Li  wrote:

> the reason is the generated code by Zicond is much larger than branch version

I'm curious about this one. It's surprising to me that we see bigger code generated with Zicond. Do you know why that is the case?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24490#issuecomment-2786233412

From jvernee at openjdk.org  Tue Apr  8 12:16:13 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 8 Apr 2025 12:16:13 GMT
Subject: RFR: 8353840: JNativeScan should not throw error for missing
 system classes
In-Reply-To: 
References: 
 
 <-DMpfwwW1NzmpeOJuZJcgiv_Vhu-IvEMtt0tmvXLeJ0=.a8f6bedf-a293-4fef-b046-709ab46781f5@github.com>
 
 
Message-ID: 

On Tue, 8 Apr 2025 12:00:41 GMT, Danish Nawab  wrote:

>>> This catch block is per-method. It means that if the rest of the method contained references to restricted methods, we would not see them. The catch block should be moved to be just around the call to isRestricted, which can fail. Then we can record the error and keep iterating over the other instructions.
>> 
>> That makes a lot of sense. I will update it.
>
>> Also, instead of passing err down to this code, I think we should define an interface for NativeMethodFinder to log diagnostics instead. e.g. something like:
> 
> This makes sense. I can update it, accordingly.
> Regarding deduplication: this means we would need to buffer the errors and print them all at the end, which would require coordination between different layers, and we might need to mark `Diagnostics` as `Closable/AutoClosable`. 
> Would it be ok for you, if the buffering/deduplication can be done a follow-up and for now we just change the termination behavior? Or do you see that as an essential component that should be included with this change?

The buffering shouldn't be hard to achieve? `JNativeScanTask::run` can just define a `Set` to which the error messages are added by the diagnostics callback. I don't see why `Diagnostics` would need to be `AutoCloseable`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24499#discussion_r2033053788

From jvernee at openjdk.org  Tue Apr  8 12:16:12 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 8 Apr 2025 12:16:12 GMT
Subject: RFR: 8353840: JNativeScan should not throw error for missing
 system classes
In-Reply-To: 
References: 
Message-ID: <2vIyofGtkgiJZ_5CV-HowmoAWhbxmHDhzTlLXe7wCFE=.de31d29a-7218-4098-886b-aa2c787f6827@github.com>

On Tue, 8 Apr 2025 08:18:36 GMT, Danish Nawab  wrote:

> ## Description
> 
> https://bugs.openjdk.org/browse/JDK-8353840 
> 
> ### Existing behavior
> Log the error message and terminate in case of missing system class
> 
> 
> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?"
> 
> ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String
> CAUSED BY: System class can not be found: sun.misc.JavaLangAccess
> Exit code: 1
> 
> 
> ### New behavior
> Still log the error message about the missing system class, but continue the analysis
> 
> 
> $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" 
> 
>   
> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess
> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets
> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets
> Exit code: 0
> 
> 
> ## Design choices
> 
> Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis
> 
> ### Alternatives considered
> 
> - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`.
>     - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception 
> - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver`
>     - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful
> 
> ### stdout vs stderr 
> 
> One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed.
> 
> ## Testing
> 
> The existing test `TestMissingSystemClass#testSingleJarClassPath` has ...

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 79:

> 77:         try(ClassResolver classesToScan = ClassResolver.forClassFileSources(toScan, version);
> 78:             ClassResolver systemClassResolver = ClassResolver.forSystemModules(version)) {
> 79:             NativeMethodFinder finder = NativeMethodFinder.create(err, classesToScan, systemClassResolver);

e.g. 
Suggestion:

            Set errors = new HashSet<>(); // print these at the end
            Diagnostics diagnostics = (context, error) -> errors.add("Error while processing " + context + ": " + error.getMessage();
            NativeMethodFinder finder = NativeMethodFinder.create(diagnostics, classesToScan, systemClassResolver);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24499#discussion_r2033057140

From pminborg at openjdk.org  Tue Apr  8 12:16:17 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 8 Apr 2025 12:16:17 GMT
Subject: RFR: 8348556: Inlining fails earlier for
 MemorySegment::reinterpret [v6]
In-Reply-To: <6wb-C25gjMYaQZXn2BFAQ2okygXAiHNxciy-zmDsy9M=.7555f6bb-2112-42d8-87ef-4ab63fab6d62@github.com>
References: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
 <6wb-C25gjMYaQZXn2BFAQ2okygXAiHNxciy-zmDsy9M=.7555f6bb-2112-42d8-87ef-4ab63fab6d62@github.com>
Message-ID: <8GSYKwHUhVFL-XjxKB9SzUyiEXVcGWnxoEr6YTnZfPE=.080d6c74-505e-41c0-84ad-2fabe5356365@github.com>

On Tue, 8 Apr 2025 11:33:54 GMT, Per Minborg  wrote:

>> This PR proposes to add some `@ForceInline` annotations in the `Module` class in order to assist inlining of FFM var/method handles.
>> 
>> There are also some changes in other classes which, if implemented, can take us three additional levels of inlining. I drew a line there. There is a tradeoff with adding `@ForceInline` and just trying to get as deep as possible for a specific use case is probably not the best idea. 
>> 
>> I have opted not to inline the `j.l.Object` constructor in anticipation of broad impact. This currently sets the depth limit for this use case.
>> 
>> Tested and passed tier1-3
>
> Per Minborg 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 nine additional commits since the last revision:
> 
>  - Revert copyright year
>  - Revert changes to Object
>  - Merge branch 'master' into module-force-inline
>  - Add more @ForceInline and a benchmark
>  - Remove reformatting
>  - Remove file
>  - Revert change
>  - Rename method and variable
>  - Add @ForceInline annotations and restructure some methods

Baseline:

Benchmark                            (offsetCount)  (segmentSize)   Mode  Cnt        Score       Error  Units
FFMVarHandleInlineTest.t0_reference           2048           1024  thrpt   25  1552613.262 ? 14295.035  ops/s
FFMVarHandleInlineTest.t1_level8              2048           1024  thrpt   25  1558465.228 ?  8458.874  ops/s
FFMVarHandleInlineTest.t2_level9              2048           1024  thrpt   25  1542009.100 ? 10240.173  ops/s
FFMVarHandleInlineTest.t3_level10             2048           1024  thrpt   25  1553407.503 ? 10834.133  ops/s
FFMVarHandleInlineTest.t4_level11             2048           1024  thrpt   25    87666.558 ?   765.848  ops/s. <-- We hit the inline limit here


Patch without `Object` changes:

Benchmark                         (offsetCount)  (segmentSize)   Mode  Cnt      Score      Error  Units
FFMVarHandleInlineTest.t_level13           2048           1024  thrpt    6  72071.657 ? 1245.304  ops/s
FFMVarHandleInlineTest.t_level14           2048           1024  thrpt    6  69263.088 ? 2196.423  ops/s
FFMVarHandleInlineTest.t_level15           2048           1024  thrpt    6   3446.827 ?  118.659  **ops/s**


Patch with `Object` changes:

Benchmark                         (offsetCount)  (segmentSize)   Mode  Cnt       Score      Error  Units
FFMVarHandleInlineTest.t_level11           2048           1024  thrpt    6  1545991.924 ? 21206.450  ops/s
FFMVarHandleInlineTest.t_level12           2048           1024  thrpt    6  1542234.193 ? 18002.511  ops/s
FFMVarHandleInlineTest.t_level13           2048           1024  thrpt    6  1542601.822 ? 15041.864  ops/s
FFMVarHandleInlineTest.t_level14           2048           1024  thrpt    6   179053.325 ?  2496.002  ops/s
FFMVarHandleInlineTest.t_level15           2048           1024  thrpt    6     3433.861 ?   165.847  ops/s

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23460#issuecomment-2786236800

From duke at openjdk.org  Tue Apr  8 12:22:18 2025
From: duke at openjdk.org (Danish Nawab)
Date: Tue, 8 Apr 2025 12:22:18 GMT
Subject: RFR: 8353840: JNativeScan should not throw error for missing
 system classes
In-Reply-To: <2vIyofGtkgiJZ_5CV-HowmoAWhbxmHDhzTlLXe7wCFE=.de31d29a-7218-4098-886b-aa2c787f6827@github.com>
References: 
 <2vIyofGtkgiJZ_5CV-HowmoAWhbxmHDhzTlLXe7wCFE=.de31d29a-7218-4098-886b-aa2c787f6827@github.com>
Message-ID: 

On Tue, 8 Apr 2025 12:12:36 GMT, Jorn Vernee  wrote:

>> ## Description
>> 
>> https://bugs.openjdk.org/browse/JDK-8353840 
>> 
>> ### Existing behavior
>> Log the error message and terminate in case of missing system class
>> 
>> 
>> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?"
>> 
>> ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String
>> CAUSED BY: System class can not be found: sun.misc.JavaLangAccess
>> Exit code: 1
>> 
>> 
>> ### New behavior
>> Still log the error message about the missing system class, but continue the analysis
>> 
>> 
>> $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" 
>> 
>>   
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets
>> Exit code: 0
>> 
>> 
>> ## Design choices
>> 
>> Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis
>> 
>> ### Alternatives considered
>> 
>> - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`.
>>     - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception 
>> - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver`
>>     - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful
>> 
>> ### stdout vs stderr 
>> 
>> One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed....
>
> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 79:
> 
>> 77:         try(ClassResolver classesToScan = ClassResolver.forClassFileSources(toScan, version);
>> 78:             ClassResolver systemClassResolver = ClassResolver.forSystemModules(version)) {
>> 79:             NativeMethodFinder finder = NativeMethodFinder.create(err, classesToScan, systemClassResolver);
> 
> e.g. 
> Suggestion:
> 
>             Set errors = new HashSet<>(); // print these at the end
>             Diagnostics diagnostics = (context, error) -> errors.add("Error while processing " + context + ": " + error.getMessage();
>             NativeMethodFinder finder = NativeMethodFinder.create(diagnostics, classesToScan, systemClassResolver);

I see what you mean. Let me take a crack at it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24499#discussion_r2033070392

From pminborg at openjdk.org  Tue Apr  8 12:24:41 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 8 Apr 2025 12:24:41 GMT
Subject: RFR: 8348556: Inlining fails earlier for
 MemorySegment::reinterpret [v7]
In-Reply-To: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
References: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
Message-ID: 

> This PR proposes to add some `@ForceInline` annotations in the `Module` class in order to assist inlining of FFM var/method handles.
> 
> There are also some changes in other classes which, if implemented, can take us three additional levels of inlining. I drew a line there. There is a tradeoff with adding `@ForceInline` and just trying to get as deep as possible for a specific use case is probably not the best idea. 
> 
> Updating the `j.l.Object` constructor is crucial for the higher depths.
> 
> Tested and passed tier1-3

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Reintroduce Object changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23460/files
  - new: https://git.openjdk.org/jdk/pull/23460/files/401d9d4f..f715b2b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23460&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23460&range=05-06

  Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23460.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23460/head:pull/23460

PR: https://git.openjdk.org/jdk/pull/23460

From jvernee at openjdk.org  Tue Apr  8 12:25:20 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 8 Apr 2025 12:25:20 GMT
Subject: RFR: 8353840: JNativeScan should not throw error for missing
 system classes
In-Reply-To: 
References: 
 <2vIyofGtkgiJZ_5CV-HowmoAWhbxmHDhzTlLXe7wCFE=.de31d29a-7218-4098-886b-aa2c787f6827@github.com>
 
Message-ID: <78kxMPeSeRBvpSxwEkYUiNxoz3lVeCSVUfNg1o1UROo=.c6866396-2762-41a2-ad00-c66f1eac066a@github.com>

On Tue, 8 Apr 2025 12:20:02 GMT, Danish Nawab  wrote:

>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 79:
>> 
>>> 77:         try(ClassResolver classesToScan = ClassResolver.forClassFileSources(toScan, version);
>>> 78:             ClassResolver systemClassResolver = ClassResolver.forSystemModules(version)) {
>>> 79:             NativeMethodFinder finder = NativeMethodFinder.create(err, classesToScan, systemClassResolver);
>> 
>> e.g. 
>> Suggestion:
>> 
>>             Set errors = new HashSet<>(); // print these at the end
>>             Diagnostics diagnostics = (context, error) -> errors.add("Error while processing " + context + ": " + error.getMessage();
>>             NativeMethodFinder finder = NativeMethodFinder.create(diagnostics, classesToScan, systemClassResolver);
>
> I see what you mean. Let me take a crack at it.

One more though: I think we should only print the error messages as part of `dumpAll` and not `printNativeAccess`, so that the result of the latter can still be piped directly to `--enable-native-access`, even if there are errors.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24499#discussion_r2033074737

From mli at openjdk.org  Tue Apr  8 12:34:22 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 8 Apr 2025 12:34:22 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L
In-Reply-To: 
References: 
Message-ID: 

On Mon, 7 Apr 2025 14:23:52 GMT, Hamlin Li  wrote:

> Hi,
> Can you help to review this patch?
> On riscv, CMoveI/L already were implemented, but there are some gap:
> 1. CMoveI/L does not support comparison with float/double, corresponding tests are not turn on either.
> 2. Some optimization of C2 is not turned on, e.g. `Phi -> CMove -> min_max`.
> 3. lack of some corresponding performance tests.
> 
> Also there are some issue with current Zicond:
> 1. UseZicond is turned on automatically by hwprobe, but jmh tests show that it's not always bring benefit, in some situation it even brings regression, the reason is the generated code by Zicond is much larger than branch version, in particular when it's in a loop and unrolled.
> 
> This patch on riscv is to:
> 1. add CMoveI/L comparing float/double, and corresponding tests,
> 2. enable more C2 optimization,
> 3. add more benchmark tests,
> 4. turn off UseZicond by default.
> 
> Thanks!
> 
> ## Performance
> 
> ### MinMax
> test data
> 
> Benchmark | Mode | Cnt | Score - master | Score - master+UseZbb | Score - -master+UseZicond | Score - master+UseZicond+UseZbb | Score - cmovei | Score - cmovei+UseZbb | Score - cmovei+UseZicond | Score - cmovei+UseZicond+UseZbb | Error | Units | Opt (master/cmovei)
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> o.o.b.vm.compiler.IfMinMax.testReductionInt | avgt | 40 | 17152.075 | 17216.592 | 17272.493 | 17296.89 | 17127.844 | 17036.605 | 17299.333 | 17250.566 | 73.179 | ns/op | 1.001
> o.o.b.vm.compiler.IfMinMax.testReductionLong | avgt | 40 | 19770.828 | 19967.578 | 20268.905 | 20166.165 | 20065.552 | 20059.095 | 20161.914 | 20151.295 | 131.428 | ns/op | 0.985
> o.o.b.vm.compiler.IfMinMax.testSingleInt | avgt | 40 | 114.734 | 114.402 | 114.887 | 114.384 | 114.4 | 110.631 | 112.162 | 110.915 | 0.333 | ns/op | 1.003
> o.o.b.vm.compiler.IfMinMax.testSingleLong | avgt | 40 | 121.53 | 121.711 | 120.91 | 121.665 | 121.309 | 120.57 | 118.639 | 119.373 | 0.451 | ns/op | 1.002
> o.o.b.vm.compiler.IfMinMax.testVectorInt | avgt | 40 | 60130.165 | 60062.303 | 61839.776 | 61895.194 | 15887.398 | 15924.502 | 15874.835 | 15667.936 | 101.94 | ns/op | 3.785
> o.o.b.vm.compiler.IfMinMax.testVectorLong | avgt | 40 | 63855.379 | 6309...

because zicond code is bigger, e.g.

void MacroAssembler::cmov_eq(Register cmp1, Register cmp2, Register dst, Register src) {
  if (UseZicond) {
    xorr(t0, cmp1, cmp2);
    czero_eqz(dst, dst, t0);
    czero_nez(t1 , src, t0);
    orr(dst, dst, t1);
    return;
  }
  Label no_set;
  bne(cmp1, cmp2, no_set);
  mv(dst, src);
  bind(no_set);
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24490#issuecomment-2786284949

From jengebr at amazon.com  Tue Apr  8 12:51:17 2025
From: jengebr at amazon.com (Engebretson, John)
Date: Tue, 8 Apr 2025 12:51:17 +0000
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: 
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 
 <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 
 
Message-ID: <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>

  Brian, Alan, Markus, Chen ? thank you for your feedback on this issue!  At this point we seem to agree that 1) there is merit to this idea, 2) nobody loves a new public class (including me), and 3) this is not a subclass of ByteArrayOutputStream.  Are we ready to move this to CSR and continue the API discussion there?
  Thank you very much!  ?
     John

From: Engebretson, John
Sent: Monday, April 7, 2025 7:36 AM
To: 'Brian Burkhalter' ; core-libs-dev at openjdk.org
Subject: RE: [EXTERNAL] JDK-8352891 Performance improvements to ByteArrayOutputStream

  Thank you Brian, I?m sorry I missed this point!  The hint in this case is the parameter on the overloaded constructor; if set high enough, the initially-allocated buffer will guarantee exactly one array allocation with no growth.  This is identical to the ByteArrayOutputStream behavior described on [1].
  However, both issues focus on the far more common case of not knowing the final payload size, or perhaps making a bad guess; [1] attempts to modify the scale while [2] rewrites the data structure for greater gain.
     John

From: core-libs-dev > On Behalf Of Brian Burkhalter
Sent: Friday, April 4, 2025 3:31 PM
To: core-libs-dev at openjdk.org
Subject: RE: [EXTERNAL] JDK-8352891 Performance improvements to ByteArrayOutputStream


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


I did not notice that Alan?s comment below, about adding a hint as to the maximum expected size, has been specifically addressed anywhere in this discussion. It might not be all that pertinent to the main thread of discussion, however, but it would certainly be useful for the issue [1], which I linked to [2].

Brian

[1] https://bugs.openjdk.org/browse/JDK-8329287
[2] https://bugs.openjdk.org/browse/JDK-8353729

On Apr 2, 2025, at 3:52?AM, Alan Bateman > wrote:

[?] and whether having a parameter to specify the initial size or some hint of the max size would help the discussion.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From sgehwolf at openjdk.org  Tue Apr  8 13:34:22 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 8 Apr 2025 13:34:22 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 7 Apr 2025 17:30:53 GMT, Alan Bateman  wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review v2
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/LinkableRuntimeImage.java line 71:
> 
>> 69:     private static InputStream getDiffInputStream(String module) throws IOException {
>> 70:         String resourceName = String.format(DIFF_PATTERN, module);
>> 71:         return JDK_JLINK_MOD.getResourceAsStream(resourceName);
> 
> FYI you can use LinkableRuntimeImage.class.getResourceAsStream here as the resource is in the current module.

It's very odd, but when I attempt this then the resource is not found. It seems to fail on the module name verification. For example: `jlink --help | tail -n2` shows as `disabled` for an enabled linkable runtime image.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2033202346

From pminborg at openjdk.org  Tue Apr  8 13:44:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 8 Apr 2025 13:44:14 GMT
Subject: RFR: 8339527: Adjust threshold for MemorySegment::fill native
 invocation
Message-ID: 

This PR proposes to increase the threshold for `MemorySegment::fill` operations on AArch-64 platforms.

Performance looks good:

![image](https://github.com/user-attachments/assets/56a83541-cb84-4a37-a914-fdddfde343c6)

![image](https://github.com/user-attachments/assets/ff2c33e0-b300-482d-b93e-217a11e07202)

-------------

Commit messages:
 - fill-threshold

Changes: https://git.openjdk.org/jdk/pull/24510/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24510&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339527
  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24510.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24510/head:pull/24510

PR: https://git.openjdk.org/jdk/pull/24510

From duke at openjdk.org  Tue Apr  8 13:47:09 2025
From: duke at openjdk.org (Danish Nawab)
Date: Tue, 8 Apr 2025 13:47:09 GMT
Subject: RFR: 8353840: JNativeScan should not throw error for missing
 system classes [v2]
In-Reply-To: 
References: 
Message-ID: 

> ## Description
> 
> https://bugs.openjdk.org/browse/JDK-8353840 
> 
> ### Existing behavior
> Log the error message and terminate in case of missing system class
> 
> 
> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?"
> 
> ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String
> CAUSED BY: System class can not be found: sun.misc.JavaLangAccess
> Exit code: 1
> 
> 
> ### New behavior
> Still log the error message about the missing system class, but continue the analysis
> 
> 
> $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" 
> 
>   
> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess
> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets
> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets
> Exit code: 0
> 
> 
> ## Design choices
> 
> Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis
> 
> ### Alternatives considered
> 
> - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`.
>     - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception 
> - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver`
>     - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful
> 
> ### stdout vs stderr 
> 
> One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed.
> 
> ## Testing
> 
> The existing test `TestMissingSystemClass#testSingleJarClassPath` has ...

Danish Nawab has updated the pull request incrementally with one additional commit since the last revision:

  8353840: improve error logging

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24499/files
  - new: https://git.openjdk.org/jdk/pull/24499/files/e658c466..3aaef9d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24499&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24499&range=00-01

  Stats: 48 lines in 4 files changed: 20 ins; 2 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/24499.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24499/head:pull/24499

PR: https://git.openjdk.org/jdk/pull/24499

From duke at openjdk.org  Tue Apr  8 13:47:10 2025
From: duke at openjdk.org (Danish Nawab)
Date: Tue, 8 Apr 2025 13:47:10 GMT
Subject: RFR: 8353840: JNativeScan should not throw error for missing
 system classes [v2]
In-Reply-To: <78kxMPeSeRBvpSxwEkYUiNxoz3lVeCSVUfNg1o1UROo=.c6866396-2762-41a2-ad00-c66f1eac066a@github.com>
References: 
 <2vIyofGtkgiJZ_5CV-HowmoAWhbxmHDhzTlLXe7wCFE=.de31d29a-7218-4098-886b-aa2c787f6827@github.com>
 
 <78kxMPeSeRBvpSxwEkYUiNxoz3lVeCSVUfNg1o1UROo=.c6866396-2762-41a2-ad00-c66f1eac066a@github.com>
Message-ID: 

On Tue, 8 Apr 2025 12:22:40 GMT, Jorn Vernee  wrote:

>> I see what you mean. Let me take a crack at it.
>
> One more thought: I think we should only print the error messages as part of `dumpAll` and not `printNativeAccess`, so that the result of the latter can still be piped directly to `--enable-native-access`, even if there are errors.

@JornVernee updated in 3aaef9d4ee3b5e8208c66ed5e3096d1afc6d5dc1

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24499#discussion_r2033224439

From duke at openjdk.org  Tue Apr  8 13:47:12 2025
From: duke at openjdk.org (Danish Nawab)
Date: Tue, 8 Apr 2025 13:47:12 GMT
Subject: RFR: 8353840: JNativeScan should not throw error for missing
 system classes [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 8 Apr 2025 13:43:54 GMT, Danish Nawab  wrote:

>> ## Description
>> 
>> https://bugs.openjdk.org/browse/JDK-8353840 
>> 
>> ### Existing behavior
>> Log the error message and terminate in case of missing system class
>> 
>> 
>> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?"
>> 
>> ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String
>> CAUSED BY: System class can not be found: sun.misc.JavaLangAccess
>> Exit code: 1
>> 
>> 
>> ### New behavior
>> Still log the error message about the missing system class, but continue the analysis
>> 
>> 
>> $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" 
>> 
>>   
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets
>> Exit code: 0
>> 
>> 
>> ## Design choices
>> 
>> Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis
>> 
>> ### Alternatives considered
>> 
>> - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`.
>>     - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception 
>> - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver`
>>     - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful
>> 
>> ### stdout vs stderr 
>> 
>> One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed....
>
> Danish Nawab has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8353840: improve error logging

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 205:

> 203:     }
> 204: 
> 205:     interface Diagnostics {

Added as an inner type since there was already precedence for that with `com.sun.tools.jnativescan.JNativeScanTask.Action`

test/langtools/tools/jnativescan/TestMissingSystemClass.java line 64:

> 62:                 .stderrAsLines();
> 63: 
> 64:         assertEquals(2, stderr.size(), "Unexpected number of lines in stderr");

To ensure that the two calls to `java.lang.Compiler.enable` have been de-duped into one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24499#discussion_r2033227648
PR Review Comment: https://git.openjdk.org/jdk/pull/24499#discussion_r2033225623

From vklang at openjdk.org  Tue Apr  8 13:51:24 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 8 Apr 2025 13:51:24 GMT
Subject: RFR: 8352971: Increase maximum number of hold counts for
 ReentrantReadWriteLock [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 8 Apr 2025 05:12:00 GMT, Jean-No?l Rouvignac  wrote:

>> Viktor Klang 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:
>> 
>>  - Make sure that the test fails in case of an InterruptedException
>>  - Adding support for more than 65k readers and writers of ReentrantReadWriteLock
>
> src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java line 1:
> 
>> 1: /*
> 
> @viktorklang-ora thank you so much for pushing this through!
> 
> There's a small nit: a co-worker noticed that this part of the javadoc is no longer true:
> 
>  * 
Implementation Notes

>  *
>  * 
This lock supports a maximum of 65535 recursive write locks
>  * and 65535 read locks. Attempts to exceed these limits result in
> * {@link Error} throws from locking methods.
> 
> 
> Thanks again!

@JnRouvignac Thanks for catching this, I've opened the following PR to amend this: https://github.com/openjdk/jdk/pull/24502/files

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24261#discussion_r2033236368

From duke at openjdk.org  Tue Apr  8 13:51:59 2025
From: duke at openjdk.org (Danish Nawab)
Date: Tue, 8 Apr 2025 13:51:59 GMT
Subject: RFR: 8353840: JNativeScan should not throw error for missing
 system classes [v3]
In-Reply-To: 
References: 
Message-ID: 

> ## Description
> 
> https://bugs.openjdk.org/browse/JDK-8353840 
> 
> ### Existing behavior
> Log the error message and terminate in case of missing system class
> 
> 
> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?"
> 
> ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String
> CAUSED BY: System class can not be found: sun.misc.JavaLangAccess
> Exit code: 1
> 
> 
> ### New behavior
> Still log the error message about the missing system class, but continue the analysis
> 
> 
> $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" 
> 
>   
> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess
> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets
> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets
> Exit code: 0
> 
> 
> ## Design choices
> 
> Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis
> 
> ### Alternatives considered
> 
> - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`.
>     - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception 
> - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver`
>     - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful
> 
> ### stdout vs stderr 
> 
> One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed.
> 
> ## Testing
> 
> The existing test `TestMissingSystemClass#testSingleJarClassPath` has ...

Danish Nawab has updated the pull request incrementally with one additional commit since the last revision:

  8353840: remove unnecessary final

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24499/files
  - new: https://git.openjdk.org/jdk/pull/24499/files/3aaef9d4..1de3feca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24499&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24499&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24499.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24499/head:pull/24499

PR: https://git.openjdk.org/jdk/pull/24499

From vklang at openjdk.org  Tue Apr  8 13:52:19 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 8 Apr 2025 13:52:19 GMT
Subject: Integrated: 8354016: Update ReentrantReadWriteLock documentation to
 reflect its new max capacity
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 09:36:09 GMT, Viktor Klang  wrote:

> Updating the ReentrantReadWriteLock documentation

This pull request has now been integrated.

Changeset: 676cfae9
Author:    Viktor Klang 
URL:       https://git.openjdk.org/jdk/commit/676cfae91c8bd4799adfedff2ad59a9aab953ece
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8354016: Update ReentrantReadWriteLock documentation to reflect its new max capacity

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/24502

From pminborg at openjdk.org  Tue Apr  8 14:05:59 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 8 Apr 2025 14:05:59 GMT
Subject: RFR: 8351757: Test java/foreign/TestDeadlock.java#FileChannel_map
 timed out after passing
Message-ID: 

This PR proposes to increase the timeout values for two tests.

-------------

Commit messages:
 - Increase timeouts

Changes: https://git.openjdk.org/jdk/pull/24511/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24511&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351757
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24511.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24511/head:pull/24511

PR: https://git.openjdk.org/jdk/pull/24511

From jvernee at openjdk.org  Tue Apr  8 14:22:21 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 8 Apr 2025 14:22:21 GMT
Subject: RFR: 8353840: JNativeScan should not throw error for missing
 system classes [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 8 Apr 2025 13:51:59 GMT, Danish Nawab  wrote:

>> ## Description
>> 
>> https://bugs.openjdk.org/browse/JDK-8353840 
>> 
>> ### Existing behavior
>> Log the error message and terminate in case of missing system class
>> 
>> 
>> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?"
>> 
>> ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String
>> CAUSED BY: System class can not be found: sun.misc.JavaLangAccess
>> Exit code: 1
>> 
>> 
>> ### New behavior
>> Still log the error message about the missing system class, but continue the analysis
>> 
>> 
>> $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" 
>> 
>>   
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets
>> Exit code: 0
>> 
>> 
>> ## Design choices
>> 
>> Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis
>> 
>> ### Alternatives considered
>> 
>> - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`.
>>     - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception 
>> - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver`
>>     - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful
>> 
>> ### stdout vs stderr 
>> 
>> One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed....
>
> Danish Nawab has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8353840: remove unnecessary final

Changes look good, thanks!

Please note that we will have to wait 24 hours before integrating, in order to give other reviews time to look as well.

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24499#pullrequestreview-2750176260

From mullan at openjdk.org  Tue Apr  8 14:23:06 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 8 Apr 2025 14:23:06 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
> 
> The current API note in these classes was reused as the deprecation text. 
> 
> Release Note: https://bugs.openjdk.org/browse/JDK-8353680

Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:

  Fix build error; add removal annotation.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24445/files
  - new: https://git.openjdk.org/jdk/pull/24445/files/8dae2f8d..cecd9287

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24445&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24445&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24445.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24445/head:pull/24445

PR: https://git.openjdk.org/jdk/pull/24445

From duke at openjdk.org  Tue Apr  8 14:28:11 2025
From: duke at openjdk.org (Danish Nawab)
Date: Tue, 8 Apr 2025 14:28:11 GMT
Subject: RFR: 8353840: JNativeScan should not throw error for missing
 system classes [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 8 Apr 2025 14:19:07 GMT, Jorn Vernee  wrote:

> Changes look good, thanks!
> 
> Please note that we will have to wait 24 hours before integrating, in order to give other reviews time to look as well.

Great, thanks for your review! 
I will wait until tomorrow to issue the `/integrate` (as instructed by openjdk[bot]). Since I am not an OpenJDK committer, I will request you to please sponsor it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24499#issuecomment-2786635915

From alanb at openjdk.org  Tue Apr  8 14:29:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 8 Apr 2025 14:29:50 GMT
Subject: RFR: 8351927: Change VirtualThread implementation to use use FJP
 delayed task handling
Message-ID: <7vE97S4zy2S1vuRwEapE4k9ZScS6yTJBQWyKymjdc0g=.5551d6d6-68ad-446e-84c7-70fd57fa57a6@github.com>

Follow up to JDK-8319447 to change the VirtualThread implementation to use FJP's delayed task handling.

The SPTE based implementation is not removed. It will continue to be used by tests. If custom schedulers are exposed in the future then they will use this implementation.

For timed-Object.wait, waitTimeoutExpired is changed to use lazySubmit to avoid signalling and increase the chance that the unparked virtual thread will continue on the current carrier. For timed-park, the timeout task is changed to reduced form of unpark that also uses lazySubmit, for the same reason.

`jcmd Thread.vthread_scheduler` is changed to no longer print the delay schedulers. Instead, the delayed task count will appear in the default scheduler output.

-------------

Commit messages:
 - Merge branch 'master' into JDK-8351927
 - Merge branch 'master' into JDK-8351927
 - Merge branch 'master' into JDK-8351927
 - Merge
 - Merge branch 'pull/23702' into JDK-8351927
 - Typo
 - Address review comments
 - Merge branch 'openjdk:master' into JDK-8319447
 - Address review comments
 - Update
 - ... and 51 more: https://git.openjdk.org/jdk/compare/867a0301...30eba776

Changes: https://git.openjdk.org/jdk/pull/24030/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24030&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351927
  Stats: 405 lines in 8 files changed: 332 ins; 41 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/24030.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24030/head:pull/24030

PR: https://git.openjdk.org/jdk/pull/24030

From pminborg at openjdk.org  Tue Apr  8 14:54:09 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 8 Apr 2025 14:54:09 GMT
Subject: RFR: 8348978: Regression ~8% on J2dBench-vimg_text_aa-ParGC only on
 linux aarch64
Message-ID: 

This PR proposes to use an anonymous class rather than a lambda in order to improve startup time.

We need to make sure the regression is fixed by this. It might be the case that the regression is there because [JDK-8347047](https://bugs.openjdk.org/browse/JDK-8347047) actually fixed an issue so that the segments could be collected by the GC.

-------------

Commit messages:
 - Replace lambda with anonymous class

Changes: https://git.openjdk.org/jdk/pull/24514/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24514&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348978
  Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24514.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24514/head:pull/24514

PR: https://git.openjdk.org/jdk/pull/24514

From rriggs at openjdk.org  Tue Apr  8 15:05:35 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 8 Apr 2025 15:05:35 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
 [v3]
In-Reply-To: 
References: 
 
Message-ID: <3DjiAo-0RHErmFMxtXjOQkl9N14GEqyDMEpzFk-YyEk=.c4d9615b-d33d-4ee8-b189-b0a86fb6f006@github.com>

On Tue, 8 Apr 2025 14:23:06 GMT, Sean Mullan  wrote:

>> Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
>> 
>> The current API note in these classes was reused as the deprecation text. 
>> 
>> Release Note: https://bugs.openjdk.org/browse/JDK-8353680
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build error; add removal annotation.

Looks good, still.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24445#pullrequestreview-2750338429

From fjiang at openjdk.org  Tue Apr  8 15:08:21 2025
From: fjiang at openjdk.org (Feilong Jiang)
Date: Tue, 8 Apr 2025 15:08:21 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L
In-Reply-To: 
References: 
Message-ID: 

On Mon, 7 Apr 2025 14:23:52 GMT, Hamlin Li  wrote:

> Hi,
> Can you help to review this patch?
> On riscv, CMoveI/L already were implemented, but there are some gap:
> 1. CMoveI/L does not support comparison with float/double, corresponding tests are not turn on either.
> 2. Some optimization of C2 is not turned on, e.g. `Phi -> CMove -> min_max`.
> 3. lack of some corresponding performance tests.
> 
> Also there are some issue with current Zicond:
> 1. UseZicond is turned on automatically by hwprobe, but jmh tests show that it's not always bring benefit, in some situation it even brings regression, the reason is the generated code by Zicond is much larger than branch version, in particular when it's in a loop and unrolled.
> 
> This patch on riscv is to:
> 1. add CMoveI/L comparing float/double, and corresponding tests,
> 2. enable more C2 optimization,
> 3. add more benchmark tests,
> 4. turn off UseZicond by default.
> 
> Thanks!
> 
> ## Performance
> 
> ### MinMax
> test data
> 
> Benchmark | Mode | Cnt | Score - master | Score - master+UseZbb | Score - -master+UseZicond | Score - master+UseZicond+UseZbb | Score - cmovei | Score - cmovei+UseZbb | Score - cmovei+UseZicond | Score - cmovei+UseZicond+UseZbb | Error | Units | Opt (master/cmovei)
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> o.o.b.vm.compiler.IfMinMax.testReductionInt | avgt | 40 | 17152.075 | 17216.592 | 17272.493 | 17296.89 | 17127.844 | 17036.605 | 17299.333 | 17250.566 | 73.179 | ns/op | 1.001
> o.o.b.vm.compiler.IfMinMax.testReductionLong | avgt | 40 | 19770.828 | 19967.578 | 20268.905 | 20166.165 | 20065.552 | 20059.095 | 20161.914 | 20151.295 | 131.428 | ns/op | 0.985
> o.o.b.vm.compiler.IfMinMax.testSingleInt | avgt | 40 | 114.734 | 114.402 | 114.887 | 114.384 | 114.4 | 110.631 | 112.162 | 110.915 | 0.333 | ns/op | 1.003
> o.o.b.vm.compiler.IfMinMax.testSingleLong | avgt | 40 | 121.53 | 121.711 | 120.91 | 121.665 | 121.309 | 120.57 | 118.639 | 119.373 | 0.451 | ns/op | 1.002
> o.o.b.vm.compiler.IfMinMax.testVectorInt | avgt | 40 | 60130.165 | 60062.303 | 61839.776 | 61895.194 | 15887.398 | 15924.502 | 15874.835 | 15667.936 | 101.94 | ns/op | 3.785
> o.o.b.vm.compiler.IfMinMax.testVectorLong | avgt | 40 | 63855.379 | 6309...

src/hotspot/cpu/riscv/riscv.ad line 9979:

> 9977: 
> 9978:   format %{
> 9979:     "CMove $dst, ($op1 $cop $op2), $dst, $src\t#@cmovI_cmpF\n\t"

Should be `CMoveI` too?

src/hotspot/cpu/riscv/riscv.ad line 9996:

> 9994: 
> 9995:   format %{
> 9996:     "CMove $dst, ($op1 $cop $op2), $dst, $src\t#@cmovI_cmpD\n\t"

Ditto.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24490#discussion_r2033403739
PR Review Comment: https://git.openjdk.org/jdk/pull/24490#discussion_r2033404091

From duke at openjdk.org  Tue Apr  8 15:13:20 2025
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 8 Apr 2025 15:13:20 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
 [v3]
In-Reply-To: 
References: 
 
Message-ID: <24wR6AVIfTd9KtlS4sK_-TAx_A5eEe1-edWjf6CurZk=.84e12340-06c5-4a27-9fb6-c35610e3e4c8@github.com>

On Tue, 8 Apr 2025 14:23:06 GMT, Sean Mullan  wrote:

>> Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
>> 
>> The current API note in these classes was reused as the deprecation text. 
>> 
>> Release Note: https://bugs.openjdk.org/browse/JDK-8353680
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build error; add removal annotation.

Marked as reviewed by dmlloyd at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24445#pullrequestreview-2750361672

From jvernee at openjdk.org  Tue Apr  8 15:20:24 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 8 Apr 2025 15:20:24 GMT
Subject: RFR: 8339527: Adjust threshold for MemorySegment::fill native
 invocation
In-Reply-To: 
References: 
Message-ID: <_H0em9QQ-A7TNOAkLTUOOb2girHnAnWvv5mY5c3VlJk=.8f23ce1b-a98c-4dbb-b072-77b8bde49206@github.com>

On Tue, 8 Apr 2025 13:37:44 GMT, Per Minborg  wrote:

> This PR proposes to increase the threshold for `MemorySegment::fill` operations on AArch-64 platforms.
> 
> Performance looks good:
> 
> ![image](https://github.com/user-attachments/assets/56a83541-cb84-4a37-a914-fdddfde343c6)
> 
> ![image](https://github.com/user-attachments/assets/ff2c33e0-b300-482d-b93e-217a11e07202)

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24510#pullrequestreview-2750396029

From jvernee at openjdk.org  Tue Apr  8 15:21:16 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 8 Apr 2025 15:21:16 GMT
Subject: RFR: 8348978: Regression ~8% on J2dBench-vimg_text_aa-ParGC only
 on linux aarch64
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 14:47:04 GMT, Per Minborg  wrote:

> This PR proposes to use an anonymous class rather than a lambda in order to improve startup time.
> 
> We need to make sure the regression is fixed by this. It might be the case that the regression is there because [JDK-8347047](https://bugs.openjdk.org/browse/JDK-8347047) actually fixed an issue so that the segments could be collected by the GC.

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 172:

> 170:                     }
> 171:                 }
> 172:                 : null;

Could you please add a comment here to explain why an anonymous class is being used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24514#discussion_r2033395739

From brian.burkhalter at oracle.com  Tue Apr  8 15:49:58 2025
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 8 Apr 2025 15:49:58 +0000
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 
 <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 
 
 <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
Message-ID: <38CB233E-A169-441A-9817-FE2EF312DD84@oracle.com>

John,

You may of course do as you like, but as a matter of personal preference I usually find it more expedient not to file a CSR until the discussion about what it will contain has become quiescent in the PR itself.

Cheers,

Brian

On Apr 8, 2025, at 5:51?AM, Engebretson, John  wrote:

Are we ready to move this to CSR and continue the API discussion there?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jengebr at amazon.com  Tue Apr  8 15:56:02 2025
From: jengebr at amazon.com (Engebretson, John)
Date: Tue, 8 Apr 2025 15:56:02 +0000
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: <38CB233E-A169-441A-9817-FE2EF312DD84@oracle.com>
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 
 <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 
 
 <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
 <38CB233E-A169-441A-9817-FE2EF312DD84@oracle.com>
Message-ID: 

  Thank you, appreciate the guidance!  ?  Will do.
    John

You may of course do as you like, but as a matter of personal preference I usually find it more expedient not to file a CSR until the discussion about what it will contain has become quiescent in the PR itself.

Cheers,

Brian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From alan.bateman at oracle.com  Tue Apr  8 16:04:04 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 8 Apr 2025 17:04:04 +0100
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 
 <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 
 
 <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
Message-ID: 

On 08/04/2025 13:51, Engebretson, John wrote:
>
> ? Brian, Alan, Markus, Chen ? thank you for your feedback on this 
> issue!? At this point we seem to agree that 1) there is merit to this 
> idea, 2) nobody loves a new public class (including me), and 3) this 
> is not a subclass of ByteArrayOutputStream.? Are we ready to move this 
> to CSR and continue the API discussion there?
>
> ? Thank you very much! ?
>
>
I think there is agreement that ByteArrayOutputStream.unsynchronized(int 
cap) (or some such method) would be useful. It would not require using a 
contiguous byte[] as the backing array so there is scope to experiment 
with implementations that don't need to resize like the base BAOS does.

Extending BOAS means the size is limited to an int. To go beyond would 
be a different API and there is lots of scope to do experiments. I think 
too early to create a CSR for MOS, assuming this is what you mean.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rriggs at openjdk.org  Tue Apr  8 16:09:27 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 8 Apr 2025 16:09:27 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v8]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 8 Apr 2025 06:41:41 GMT, Alan Bateman  wrote:

>> 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:
>> 
>>  - Revert "Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions."
>>    SecureClassLoader.getPermissions and URLClassLoader.getPermissions are not marked as Deprecated.
>>  - Merge branch 'master' into 8353641-deprecate-premission-classes
>>  - Missing suppresswarnings
>>  - Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions.
>>    Remove dead code from ForkJoinPool.
>>    Add @SuppressWarnings("remove")
>>  - Remove unnecessary SuppressWarnings and correct Deprecated annotation style
>>  - Update copyright in WindowsFileCopy
>>  - Remove unused import of LinkPermission
>>  - Updated style of @Deprecated to match most existing @Deprecated annotations
>>    `since` comes before `forRemoval`
>>    No spaces around `=`
>>  - Add SuppressWarnings to a Windows source missed earlier.
>>  - 8353641: Deprecate core library permission classes for removal
>>    
>>    Now that the Security Manager is permanently disabled, the following permission classes
>>    in the core libraries area can be deprecated for removal as they are no longer useful:
>>    FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission,
>>    RuntimePermission, and SerializablePermission
>>    
>>    @Deprecated(forRemoval = true, since="25")
>>    Is added to each class and the existing @apiNote is converted to @deprected
>
> src/java.base/share/classes/jdk/internal/access/JavaIOFilePermissionAccess.java line 49:
> 
>> 47:      */
>> 48:     @SuppressWarnings("removal")
>> 49:     FilePermission newPermUsingAltPath(FilePermission input);
> 
> I assume JavaIOFilePermissionAccess can be removed, nothing should be using this now.

Filed JDK-8354053 to remove as a separate issue.

> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java line 443:
> 
>> 441:     @SuppressWarnings("removal")
>> 442:     private void defineTransletClasses()
>> 443:         throws TransformerConfigurationException {
> 
> In passing, the PermissionCollection used to construct the PD here is no longer needed. If this is cleaned up then the SW wouldn't be needed.

Filed JDK-8354054 to cleanup in a separate issue.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2033542174
PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2033538959

From mullan at openjdk.org  Tue Apr  8 16:16:24 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 8 Apr 2025 16:16:24 GMT
Subject: Integrated: 8348967: Deprecate security permission classes for removal
In-Reply-To: 
References: 
Message-ID: 

On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan  wrote:

> Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
> 
> The current API note in these classes was reused as the deprecation text. 
> 
> Release Note: https://bugs.openjdk.org/browse/JDK-8353680

This pull request has now been integrated.

Changeset: 3cbe686d
Author:    Sean Mullan 
URL:       https://git.openjdk.org/jdk/commit/3cbe686d6203043e95604b3d6c96d6ed9d5364c3
Stats:     36 lines in 11 files changed: 20 ins; 0 del; 16 mod

8348967: Deprecate security permission classes for removal

Reviewed-by: rriggs, iris

-------------

PR: https://git.openjdk.org/jdk/pull/24445

From rriggs at openjdk.org  Tue Apr  8 16:16:23 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 8 Apr 2025 16:16:23 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 8 Apr 2025 14:23:06 GMT, Sean Mullan  wrote:

>> Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
>> 
>> The current API note in these classes was reused as the deprecation text. 
>> 
>> Release Note: https://bugs.openjdk.org/browse/JDK-8353680
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build error; add removal annotation.

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24445#pullrequestreview-2750589286

From liach at openjdk.org  Tue Apr  8 16:19:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Apr 2025 16:19:18 GMT
Subject: RFR: 8353683: [REDO] j.u.l.Handler classes create deadlock risk
 via synchronized publish() method
In-Reply-To: <2l5AHWU2u5_pJSlTHuCbW4NXM6Rzdq1vjvvoca0wKC0=.0a9cfc62-70dc-498e-816e-469ffbbca9ce@github.com>
References: <2l5AHWU2u5_pJSlTHuCbW4NXM6Rzdq1vjvvoca0wKC0=.0a9cfc62-70dc-498e-816e-469ffbbca9ce@github.com>
Message-ID: <1hi7sIiW2Watca8P_a-LmCWFPEmXd3tFxoumdgfqWfA=.ecc0ba28-be14-48f2-bd5d-d238cb0ec070@github.com>

On Tue, 8 Apr 2025 11:00:27 GMT, David Beaumont  wrote:

> 8353683: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

src/java.logging/share/classes/java/util/logging/Handler.java line 46:

> 44:  * {@code Handler} class.
> 45:  *
> 46:  * 
Thread Safety and Deadlock Risk in Handlers


FYI you can add the id attribute to the h2 tag without declaring a separate a tag.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24504#discussion_r2033559665

From pminborg at openjdk.org  Tue Apr  8 16:37:23 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 8 Apr 2025 16:37:23 GMT
Subject: Integrated: 8339527: Adjust threshold for MemorySegment::fill native
 invocation
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 13:37:44 GMT, Per Minborg  wrote:

> This PR proposes to increase the threshold for `MemorySegment::fill` operations on AArch-64 platforms.
> 
> Performance looks good:
> 
> ![image](https://github.com/user-attachments/assets/56a83541-cb84-4a37-a914-fdddfde343c6)
> 
> ![image](https://github.com/user-attachments/assets/ff2c33e0-b300-482d-b93e-217a11e07202)

This pull request has now been integrated.

Changeset: b98d6aeb
Author:    Per Minborg 
URL:       https://git.openjdk.org/jdk/commit/b98d6aebdd897959785ea27ee7855d26c9ed35d7
Stats:     4 lines in 1 file changed: 0 ins; 2 del; 2 mod

8339527: Adjust threshold for MemorySegment::fill native invocation

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/24510

From pminborg at openjdk.org  Tue Apr  8 16:40:06 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 8 Apr 2025 16:40:06 GMT
Subject: RFR: 8348978: Regression ~8% on J2dBench-vimg_text_aa-ParGC only
 on linux aarch64 [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposes to use an anonymous class rather than a lambda in order to improve startup time.
> 
> We need to make sure the regression is fixed by this. It might be the case that the regression is there because [JDK-8347047](https://bugs.openjdk.org/browse/JDK-8347047) actually fixed an issue so that the segments could be collected by the GC.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add comment on anonymous class

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24514/files
  - new: https://git.openjdk.org/jdk/pull/24514/files/98975dc9..49c4b352

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24514&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24514&range=00-01

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24514.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24514/head:pull/24514

PR: https://git.openjdk.org/jdk/pull/24514

From alanb at openjdk.org  Tue Apr  8 16:54:17 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 8 Apr 2025 16:54:17 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG  wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'

I think the API docs in the latest draft looks okay. It mildly bothers me a bit is that getChars is JDK 1.0 API but the trade off with doing a new API is that it would need to be implemented by String and SB so I think the proposal on the table is okay.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2787087670

From duke at openjdk.org  Tue Apr  8 17:07:30 2025
From: duke at openjdk.org (Markus KARG)
Date: Tue, 8 Apr 2025 17:07:30 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: 
References: 
 
 
Message-ID: <3_9EK7Fh7EyKrg-5msgTMYB-icpPwvBRL5v7bXWdsTA=.ed4bda82-a9cb-43e9-be32-416cdef6a3da@github.com>

On Tue, 8 Apr 2025 16:51:06 GMT, Alan Bateman  wrote:

> I think the API docs in the latest draft looks okay. It mildly bothers me a bit is that getChars is JDK 1.0 API but the trade off with doing a new API is that it would need to be implemented by String and SB so I think the proposal on the table is okay.

Kindly asking to mark this PR as reviewed, so I will go on with the CSR next.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2787121134

From iklam at openjdk.org  Tue Apr  8 17:40:17 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 8 Apr 2025 17:40:17 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v5]
In-Reply-To: <9nX8O13jWi7qORu4uO-ppDmlph2W2lH1VVIKFP3-Gt8=.46545db1-b218-497d-b4ef-546410b09b9b@github.com>
References: 
 <9nX8O13jWi7qORu4uO-ppDmlph2W2lH1VVIKFP3-Gt8=.46545db1-b218-497d-b4ef-546410b09b9b@github.com>
Message-ID: 

On Tue, 8 Apr 2025 12:09:59 GMT, Timofei Pushkin  wrote:

>> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app.
>> 
>> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible.
>
> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary scoping

Changes requested by iklam (Reviewer).

src/java.base/share/classes/jdk/internal/misc/CDS.java line 438:

> 436:             // class loader. Thus it is safe to delegate their loading to system class loader
> 437:             // (our parent) - this is what the default implementation of loadClass() will do.
> 438:             return defineClass(name, bytes, 0, bytes.length);

I didn't realize that `URLClassLoader` will by default delegate to `ClassLoader::getSystemClassLoader()`. How about rewording the comments like this to clarify?


// defineClass() will internally invoke loadClass() to load supertypes of this unregistered class.
// Any supertype S with the name SN must have already been loaded (enforced by the order
// of classes in the classlist). In addition:
// - if S is an unregistered class, S must have already been have been defined by the current class
//   loader, and will be found by `this.findLoadedClass(SN)`
// - if S is not an unregistered class, S must have already been defined by the built-in boot,
//   platform, or system class loaders, and can be found by this.getParent().loadClass(SN, false)
// See the implementation of ClassLoader::loadClass() for details.
//
// Therefore, we should resolve all supertypes to the expected ones as specified by the
// super: and interfaces: attributes in the classlist. This
// invariance is validated by the C++ function ClassListParser::load_class_from_source()
assert getParent() == getSystemClassLoader();
return defineClass(name, bytes, 0, bytes.length);

-------------

PR Review: https://git.openjdk.org/jdk/pull/24223#pullrequestreview-2750817568
PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2033724629

From iklam at openjdk.org  Tue Apr  8 17:40:18 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 8 Apr 2025 17:40:18 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v4]
In-Reply-To: 
References: 
 <_jUyfQOHTQHeuKp72nHVOjSJJZtmjx-6ViBd9qi-IpA=.06a4213b-7834-4eda-b50f-4d362bbb761c@github.com>
 
 
Message-ID: <59RkPepnIk-FSEkX13j1-H60yc6q_B-JEmV-Fa6BKUQ=.01d7e227-3873-4805-8c41-fa1aab1a3713@github.com>

On Tue, 8 Apr 2025 11:46:27 GMT, Timofei Pushkin  wrote:

>> src/java.base/share/classes/jdk/internal/misc/CDS.java line 444:
>> 
>>> 442:         protected Class findClass(String name) throws ClassNotFoundException {
>>> 443:             // Unregistered classes should be found in load(...), registered classes should be
>>> 444:             // handeled by parent loaders
>> 
>> Hmm, I wonder how the reference to java.lang.Object is resolved in this case. When `CustomLoadee` is parsed, the ClassFileParser needs to resolve is super class, which should result into a call to `UnregisteredClassLoader::findClass()`.
>> 
>> 
>>             "java/lang/Object id: 0",
>>             "CustomLoadee id: 1 super: 0 source: .",
>
> `UnregisteredClassLoader::loadClass` will be called, i.e. the default implementation from `ClassLoader::loadClass`, which will first try to delegate to parent. The delegation chain will reach the boot loader which will find `java.lang.Object` and thus `UnregisteredClassLoader::findClass()` won't be called.

I think the findClass() method can be deleted as it's identical to the one in URLClassLoader.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2033685869

From jlu at openjdk.org  Tue Apr  8 17:40:24 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 8 Apr 2025 17:40:24 GMT
Subject: Integrated: 8353713: Improve Currency.getInstance exception handling
In-Reply-To: 
References: 
Message-ID: 

On Fri, 4 Apr 2025 21:25:00 GMT, Justin Lu  wrote:

> Please review this PR which improves some Currency `IllegalArgumentException`s by including the input in the message. This could be a currency code, country code, or locale. This change also includes tests to check the messages for an invalid country via the region override as well as an invalid country code within a 3 length currency code.

This pull request has now been integrated.

Changeset: 5cac5796
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/5cac579619164b9a664327a4f71c4de7e7575276
Stats:     37 lines in 2 files changed: 12 ins; 0 del; 25 mod

8353713: Improve Currency.getInstance exception handling

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/24459

From duke at openjdk.org  Tue Apr  8 17:40:51 2025
From: duke at openjdk.org (kabutz)
Date: Tue, 8 Apr 2025 17:40:51 GMT
Subject: RFR: 8354060: LinkedBlockingDeque.clear() should preserve
 weakly-consistent iterators
Message-ID: 

LinkedBlockingDeque.clear() should preserve weakly-consistent iterators by linking f.prev and f.next back to f, allowing the iterators to continue from the first or last respectively. This would be consistent with how the other node-based weakly consistent queues LinkedBlockingQueue LinkedTransferQueue, ConcurrentLinkedQueue/Deque work.

The LBD already supports self-linking, since that is done by the unlinkFirst() and unlinkLast() methods, and the iterators and spliterator all support this.

This can be fixed very easily by linking both f.prev and f.next back to f.

-------------

Commit messages:
 - Added self-link to nodes during clear(), to make weakly-consistent iteration consistent with other linked data structures.

Changes: https://git.openjdk.org/jdk/pull/24488/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24488&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354060
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24488.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24488/head:pull/24488

PR: https://git.openjdk.org/jdk/pull/24488

From duke at openjdk.org  Tue Apr  8 18:07:18 2025
From: duke at openjdk.org (Johannes Graham)
Date: Tue, 8 Apr 2025 18:07:18 GMT
Subject: RFR: 8353741: Improve UUID.toString performance by using SIMD
 within a register instead of table lookup [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 5 Apr 2025 05:30:25 GMT, Shaojin Wen  wrote:

>> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD within a register) instead of table lookup. Eliminating the table lookup can also avoid the performance degradation problem when the cache misses.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify code

Have you considered removing `reverseBytes` and using `ByteArray` instead of `ByteArrayLittleEndian`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22928#issuecomment-2787268424

From liach at openjdk.org  Tue Apr  8 18:14:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Apr 2025 18:14:32 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: 
References: 
 
Message-ID: <4U3TP4zVn6Bg39f6rLOCDT97Zfj33DEMrJm2seoatN4=.155d1292-2a03-4b5b-ad7e-62adf9bd2be7@github.com>

On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG  wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'

Should we ask hotspot compiler engineers for inputs on how useful this API is for allowing batch/vectorized copy and eliminating overheads of defensive copy array allocation?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2787292309

From weijun at openjdk.org  Tue Apr  8 18:19:46 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 8 Apr 2025 18:19:46 GMT
Subject: RFR: 8353888: Implement Key Derivation Function API
Message-ID: 

Finalize the KDF API.

-------------

Commit messages:
 - the change

Changes: https://git.openjdk.org/jdk/pull/24520/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353888
  Stats: 42 lines in 16 files changed: 0 ins; 30 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/24520.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24520/head:pull/24520

PR: https://git.openjdk.org/jdk/pull/24520

From duke at openjdk.org  Tue Apr  8 19:14:28 2025
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Tue, 8 Apr 2025 19:14:28 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11]
In-Reply-To: 
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 
Message-ID: 

On Sun, 22 Oct 2023 17:26:52 GMT, Laurent Bourg?s  wrote:

>> * improved  mixed insertion sort (makes whole sorting faster)
>> * introduced Radix which sort shows several times boost of performance and has linear complexity instead of n*ln(n)
>> * improved merging sort for almost sorted data
>> * optimized parallel sorting
>> * improved step for pivot candidates and pivot partitioning
>> * extended existing tests
>> * added benchmarking JMH tests
>> * suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError, threshold is 1/16th heap
>> 
>> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938
>
> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add @SuppressWarnings (serial)

Need time to check test coverage

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-2787430223

From liach at openjdk.org  Tue Apr  8 19:39:16 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Apr 2025 19:39:16 GMT
Subject: RFR: 8353888: Implement Key Derivation Function API
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 18:14:53 GMT, Weijun Wang  wrote:

> Finalize the KDF API.

Changes requested by liach (Reviewer).

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 82:

> 80:         MODULE_IMPORTS,
> 81:         @JEP(number=478, title="Key Derivation Function API", status="Preview")
> 82:         KEY_DERIVATION,

Please keep this constant - we cannot remove this until our minimum boot JDK is 25.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24520#pullrequestreview-2751196660
PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2033904746

From vklang at openjdk.org  Tue Apr  8 20:09:25 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 8 Apr 2025 20:09:25 GMT
Subject: RFR: 8351927: Change VirtualThread implementation to use use FJP
 delayed task handling
In-Reply-To: <7vE97S4zy2S1vuRwEapE4k9ZScS6yTJBQWyKymjdc0g=.5551d6d6-68ad-446e-84c7-70fd57fa57a6@github.com>
References: <7vE97S4zy2S1vuRwEapE4k9ZScS6yTJBQWyKymjdc0g=.5551d6d6-68ad-446e-84c7-70fd57fa57a6@github.com>
Message-ID: <64xe_dZIfIScyB_InbjJJn19DjAY_7qxmsB7FKKKIH4=.0c4ad76a-cbf8-475d-b3e8-6c2336ec1f29@github.com>

On Thu, 13 Mar 2025 10:48:14 GMT, Alan Bateman  wrote:

> Follow up to JDK-8319447 to change the VirtualThread implementation to use FJP's delayed task handling.
> 
> The SPTE based implementation is not removed. It will continue to be used by tests. If custom schedulers are exposed in the future then they will use this implementation.
> 
> For timed-Object.wait, waitTimeoutExpired is changed to use lazySubmit to avoid signalling and increase the chance that the unparked virtual thread will continue on the current carrier. For timed-park, the timeout task is changed to reduced form of unpark that also uses lazySubmit, for the same reason.
> 
> `jcmd Thread.vthread_scheduler` is changed to no longer print the delay schedulers. Instead, the delayed task count will appear in the default scheduler output.

src/java.base/share/classes/java/lang/VirtualThread.java line 889:

> 887:     private void parkTimeoutExpired() {
> 888:         assert !VirtualThread.currentThread().isVirtual();
> 889:         if (!getAndSetParkPermit(true)

@AlanBateman Would it make sense to test whether the park-permit is false before the LOCK XCHG?

src/java.base/share/classes/java/lang/VirtualThread.java line 1455:

> 1453:             return pool.schedule(command, delay, unit);
> 1454:         } else {
> 1455:             return DelayedTaskSchedulers.schedule(command, delay, unit);

@AlanBateman Would it make sense to test if the Scheduler implements ScheduledExecutorService?

src/java.base/share/classes/java/lang/VirtualThread.java line 1462:

> 1460:      * Supports scheduling a runnable task to run after a delay. It uses a number
> 1461:      * of ScheduledThreadPoolExecutor instances to reduce contention on the delayed
> 1462:      * work queue used. This class is used when using a custom scheduler.

@AlanBateman It might make sense to instead require a custom Scheduler to implement ScheduledExecutorService? ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24030#discussion_r2033942539
PR Review Comment: https://git.openjdk.org/jdk/pull/24030#discussion_r2033943663
PR Review Comment: https://git.openjdk.org/jdk/pull/24030#discussion_r2033944680

From bchristi at openjdk.org  Tue Apr  8 20:27:50 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 8 Apr 2025 20:27:50 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests
Message-ID: 

Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead to intermittent test failures ([JDK-8298783](https://bugs.openjdk.org/browse/JDK-8298783)  is a recent example).

A better mechanism already exists in the private `Reference.waitForReferenceProcessing()` method. This PR makes `waitForReferenceProcessing()` available to tests via the `WhiteBox` and `ForceGC` test libraries.

-------------

Commit messages:
 - add waitForReferenceProcessing() to WhiteBox and ForceGC

Changes: https://git.openjdk.org/jdk/pull/24527/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24527&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305186
  Stats: 57 lines in 2 files changed: 55 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24527/head:pull/24527

PR: https://git.openjdk.org/jdk/pull/24527

From liach at openjdk.org  Tue Apr  8 20:40:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Apr 2025 20:40:53 GMT
Subject: RFR: 8352748: Remove com.sun.tools.classfile from the JDK
Message-ID: 

With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.

Testing: built locally, running tier 1-3 tests

Don't know why, but GitHub is redundantly displaying changes that are already in #24212.

-------------

Depends on: https://git.openjdk.org/jdk/pull/24212

Commit messages:
 - 8352748: Remove com.sun.tools.classfile from the JDK
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
 - Other references to remove
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
 - FieldDescription.constantValue uses Integer for byte and short
 - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

Changes: https://git.openjdk.org/jdk/pull/24528/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24528&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352748
  Stats: 11072 lines in 74 files changed: 42 ins; 10705 del; 325 mod
  Patch: https://git.openjdk.org/jdk/pull/24528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24528/head:pull/24528

PR: https://git.openjdk.org/jdk/pull/24528

From weijun at openjdk.org  Tue Apr  8 21:03:17 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 8 Apr 2025 21:03:17 GMT
Subject: RFR: 8353888: Implement Key Derivation Function API
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 8 Apr 2025 19:35:33 GMT, Chen Liang  wrote:

>> Finalize the KDF API.
>
> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 82:
> 
>> 80:         MODULE_IMPORTS,
>> 81:         @JEP(number=478, title="Key Derivation Function API", status="Preview")
>> 82:         KEY_DERIVATION,
> 
> Please keep this constant - we cannot remove this until our minimum boot JDK is 25.

Oh, I didn't know that. I've built this with JDK 24 as the boot JDK and see no problem.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2034027369

From liach at openjdk.org  Tue Apr  8 21:06:23 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Apr 2025 21:06:23 GMT
Subject: RFR: 8353888: Implement Key Derivation Function API
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 8 Apr 2025 21:00:41 GMT, Weijun Wang  wrote:

>> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 82:
>> 
>>> 80:         MODULE_IMPORTS,
>>> 81:         @JEP(number=478, title="Key Derivation Function API", status="Preview")
>>> 82:         KEY_DERIVATION,
>> 
>> Please keep this constant - we cannot remove this until our minimum boot JDK is 25.
>
> Oh, I didn't know that. I've built this with JDK 24 as the boot JDK and see no problem.

I think the dependency is in the CreateSymbols tool or something

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2034030628

From rriggs at openjdk.org  Tue Apr  8 21:22:28 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 8 Apr 2025 21:22:28 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 20:20:56 GMT, Brent Christian  wrote:

> Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead to intermittent test failures ([JDK-8298783](https://bugs.openjdk.org/browse/JDK-8298783)  is a recent example).
> 
> A better mechanism already exists in the private `Reference.waitForReferenceProcessing()` method. This PR makes `waitForReferenceProcessing()` available to tests via the `WhiteBox` and `ForceGC` test libraries.

test/lib/jdk/test/lib/util/ForceGC.java line 125:

> 123:                 Method[] methods = refClass.getDeclaredMethods();
> 124:                 wfrp = Arrays.stream(methods).filter((m) -> m.getName().equals("waitForReferenceProcessing")).findFirst().get();
> 125:                 wfrp.setAccessible(true);

You don't need the stream.  
Suggestion:

                Method wfrp = Reference.class.getDeclaredMethod("waitForReferenceProcessing");
                wfrp.setAccessible(true);

test/lib/jdk/test/whitebox/WhiteBox.java line 569:

> 567:    * This method should usually be called after a call to WhiteBox.fullGC().
> 568:    */
> 569:   public static void waitForReferenceProcessing() {

Can the code duplication be avoided?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2034045556
PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2034048421

From kbarrett at openjdk.org  Tue Apr  8 22:47:31 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 8 Apr 2025 22:47:31 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 20:20:56 GMT, Brent Christian  wrote:

> Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead to intermittent test failures ([JDK-8298783](https://bugs.openjdk.org/browse/JDK-8298783)  is a recent example).
> 
> A better mechanism already exists in the private `Reference.waitForReferenceProcessing()` method. This PR makes `waitForReferenceProcessing()` available to tests via the `WhiteBox` and `ForceGC` test libraries.

test/lib/jdk/test/lib/util/ForceGC.java line 117:

> 115:      * jtreg tag.
> 116:      *
> 117:      * This method should usually be called after a call to WhiteBox.fullGC().

I suggest waiting until we have a use-case for WFRP _without_ `WB.fullGC` before adding this.
That's because I'm doubtful that such a use-case exists.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2034131990

From bpb at openjdk.org  Tue Apr  8 22:56:53 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 8 Apr 2025 22:56:53 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v12]
In-Reply-To: 
References: 
Message-ID: 

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge
 - Merge
 - Merge
 - Merge
 - 8337143: Minor makefile tweak
 - 8337143: Clean up to address reviewer comments
 - Merge
 - 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
 - Merge
 - 8337143: Removed dependency of libjava on headers in libnio/ch
 - ... and 2 more: https://git.openjdk.org/jdk/compare/5b42c46b...3e1e15dc

-------------

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=11
  Stats: 1541 lines in 93 files changed: 774 ins; 668 del; 99 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

PR: https://git.openjdk.org/jdk/pull/20317

From bchristi at openjdk.org  Tue Apr  8 22:58:30 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 8 Apr 2025 22:58:30 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 8 Apr 2025 21:19:06 GMT, Roger Riggs  wrote:

>> Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead to intermittent test failures ([JDK-8298783](https://bugs.openjdk.org/browse/JDK-8298783)  is a recent example).
>> 
>> A better mechanism already exists in the private `Reference.waitForReferenceProcessing()` method. This PR makes `waitForReferenceProcessing()` available to tests via the `WhiteBox` and `ForceGC` test libraries.
>
> test/lib/jdk/test/whitebox/WhiteBox.java line 569:
> 
>> 567:    * This method should usually be called after a call to WhiteBox.fullGC().
>> 568:    */
>> 569:   public static void waitForReferenceProcessing() {
> 
> Can the code duplication be avoided?

That would be nice.
A primary goal here is to not disrupt existing tests that use `WhiteBox` or `ForceGC`, (e.g. by necessitating additional tags, `@run` arguments, etc).
I don't think there's a way for `WhiteBox.java` and `ForceGC.java` to both refer to code at some shared location without tests having to add a new tag - `@build`, I think.
However I will look into it a bit further.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2034139841

From weijun at openjdk.org  Tue Apr  8 23:39:42 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 8 Apr 2025 23:39:42 GMT
Subject: RFR: 8353888: Implement Key Derivation Function API [v2]
In-Reply-To: 
References: 
Message-ID: 

> Finalize the KDF API.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  add enum back

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24520/files
  - new: https://git.openjdk.org/jdk/pull/24520/files/4ff3b95b..66706a50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24520.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24520/head:pull/24520

PR: https://git.openjdk.org/jdk/pull/24520

From duke at openjdk.org  Wed Apr  9 03:06:42 2025
From: duke at openjdk.org (duke)
Date: Wed, 9 Apr 2025 03:06:42 GMT
Subject: Withdrawn: 8069345: (fs) FileTreeWalker throws NotDirectoryException
 on file junction points
In-Reply-To: 
References: 
Message-ID: 

On Thu, 17 Oct 2024 00:05:26 GMT, Brian Burkhalter  wrote:

> Improve support for Windows directory junctions.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21555

From fyang at openjdk.org  Wed Apr  9 04:02:29 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 9 Apr 2025 04:02:29 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v2]
In-Reply-To: <1pa1FDH5Z2quR3fE7o4qfZKwRrz8nXHbMSirSyiqhTw=.9c37d2a9-5b93-40dd-8b5a-a5822030ef48@github.com>
References: 
 
 
 <1pa1FDH5Z2quR3fE7o4qfZKwRrz8nXHbMSirSyiqhTw=.9c37d2a9-5b93-40dd-8b5a-a5822030ef48@github.com>
Message-ID: <9R7U8cL4aSOayHQzaXoTGx0nXSXqdkO4ZomONZnM0Ao=.c1c90e1c-3085-4656-911d-23c407cff74d@github.com>

On Fri, 28 Mar 2025 06:53:15 GMT, Robbin Ehn  wrote:

> It's not some intermittently failure. The majority of them can't work as they use pstack, open core files, use PerfData, etc.. and expected it to be rv64. But core files, pstack are in host arch as we are running qemu-user. I can remove tests which timeouts and only keep test which simply can't work in qemu-user environment in this PR. Seems good?

Hi, That make sense to me. And it doesn't seem to me to be riscv-specific issue, but rather one with qemu-user. Maybe we should update the title and changes to reflect that? I sometimes see people testing with qemu for other CPU platforms as well like ppc, s390, etc. Guess they might be helped with this too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2788216103

From alanb at openjdk.org  Wed Apr  9 05:59:32 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 05:59:32 GMT
Subject: RFR: 8351927: Change VirtualThread implementation to use use FJP
 delayed task handling
In-Reply-To: <64xe_dZIfIScyB_InbjJJn19DjAY_7qxmsB7FKKKIH4=.0c4ad76a-cbf8-475d-b3e8-6c2336ec1f29@github.com>
References: <7vE97S4zy2S1vuRwEapE4k9ZScS6yTJBQWyKymjdc0g=.5551d6d6-68ad-446e-84c7-70fd57fa57a6@github.com>
 <64xe_dZIfIScyB_InbjJJn19DjAY_7qxmsB7FKKKIH4=.0c4ad76a-cbf8-475d-b3e8-6c2336ec1f29@github.com>
Message-ID: 

On Tue, 8 Apr 2025 20:05:26 GMT, Viktor Klang  wrote:

>> Follow up to JDK-8319447 to change the VirtualThread implementation to use FJP's delayed task handling.
>> 
>> The SPTE based implementation is not removed. It will continue to be used by tests. If custom schedulers are exposed in the future then they will use this implementation.
>> 
>> For timed-Object.wait, waitTimeoutExpired is changed to use lazySubmit to avoid signalling and increase the chance that the unparked virtual thread will continue on the current carrier. For timed-park, the timeout task is changed to reduced form of unpark that also uses lazySubmit, for the same reason.
>> 
>> `jcmd Thread.vthread_scheduler` is changed to no longer print the delay schedulers. Instead, the delayed task count will appear in the default scheduler output.
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 889:
> 
>> 887:     private void parkTimeoutExpired() {
>> 888:         assert !VirtualThread.currentThread().isVirtual();
>> 889:         if (!getAndSetParkPermit(true)
> 
> @AlanBateman Would it make sense to test whether the park-permit is false before the LOCK XCHG?

It already does, no CAS if the current value is the new value.

> src/java.base/share/classes/java/lang/VirtualThread.java line 1455:
> 
>> 1453:             return pool.schedule(command, delay, unit);
>> 1454:         } else {
>> 1455:             return DelayedTaskSchedulers.schedule(command, delay, unit);
> 
> @AlanBateman Would it make sense to test if the Scheduler implements ScheduledExecutorService?

Not for now. If a custom scheduler feature is exposed some time then we can think about this topic, it may or may be that the custom scheduler supports delayed tasks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24030#discussion_r2034500634
PR Review Comment: https://git.openjdk.org/jdk/pull/24030#discussion_r2034500533

From alanb at openjdk.org  Wed Apr  9 06:16:45 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 06:16:45 GMT
Subject: RFR: 8353888: Implement Key Derivation Function API [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 8 Apr 2025 21:03:18 GMT, Chen Liang  wrote:

>> Oh, I didn't know that. I've built this with JDK 24 as the boot JDK and see no problem.
>
> I think the dependency is in the CreateSymbols tool or something

Yes, we've had issues with boot cycle builds at least, Jan has the details and I think the guidance the last time was to leave it in place to the next release.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2034519284

From rehn at openjdk.org  Wed Apr  9 06:34:30 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 9 Apr 2025 06:34:30 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v2]
In-Reply-To: <9R7U8cL4aSOayHQzaXoTGx0nXSXqdkO4ZomONZnM0Ao=.c1c90e1c-3085-4656-911d-23c407cff74d@github.com>
References: 
 
 
 <1pa1FDH5Z2quR3fE7o4qfZKwRrz8nXHbMSirSyiqhTw=.9c37d2a9-5b93-40dd-8b5a-a5822030ef48@github.com>
 <9R7U8cL4aSOayHQzaXoTGx0nXSXqdkO4ZomONZnM0Ao=.c1c90e1c-3085-4656-911d-23c407cff74d@github.com>
Message-ID: 

On Wed, 9 Apr 2025 03:57:10 GMT, Fei Yang  wrote:

> > It's not some intermittently failure. The majority of them can't work as they use pstack, open core files, use PerfData, etc.. and expected it to be rv64. But core files, pstack are in host arch as we are running qemu-user. I can remove tests which timeouts and only keep test which simply can't work in qemu-user environment in this PR. Seems good?
> 
> Hi, That make sense to me. And it doesn't seem to me to be riscv-specific issue, but rather one with qemu-user. Maybe we should update the title and changes to reflect that? I sometimes see people testing with qemu for other CPU platforms as well like ppc, s390, etc. Guess they might be helped with this too.

Hey, thanks for considering.
The default qemu /proc/cpu do not contain any information about this being qemu.
And there is no standard way to find this out AFIAK.
Some platforms have target specific /proc/cpu and put qemu in there, but it have no standard format.
The whole proc -> uarch string -> jvm cpu string -> jtreg require is qemu/linux-user/riscv specific.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2788434073

From fyang at openjdk.org  Wed Apr  9 06:57:42 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 9 Apr 2025 06:57:42 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 8 Apr 2025 10:29:38 GMT, Hamlin Li  wrote:

> > Maybe we should check UseZicond and only enable UseCMoveUnconditionally & ConditionalMoveLimit conditionally?
> 
> Not sure what do you mean here.

Sorry for not being clear enough. I am suggesting this:


  if (UseZicond) {
    FLAG_SET_DEFAULT(ConditionalMoveLimit, 3);
  }


Without `Zicond` extension, conditional moves composed by C2 are simply emulated with regular conditional branches on riscv, which I think is not good in respect of performance.

>> src/hotspot/cpu/riscv/vm_version_riscv.cpp line 461:
>> 
>>> 459:     FLAG_SET_DEFAULT(UseZicond, false);
>>> 460:     warning("UseZicond is turned off automatically. Turn it on with -XX:+UseZicond explicitly.");
>>> 461:   }
>> 
>> Does this mean `UseZicond` could not be enabled on the command line? And I witnessed quite some warning when doing a native build. If `UseZicond` causes regression for some cases, is it more reasonable to not auto-enable it through hwprobe [1]? Or only enable it for debug builds like https://github.com/openjdk/jdk/pull/24478 does?
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp#L228
>
> This is to not enable Zicond automatically, but user can still turn it on manually if they want to try or make sure it bring benefit on the specific hardware.
> Currently it's based on bananapi result, so maybe  in the future we should adjust the default value of UseZicond.
> I'm fine with either default value.

I just witnessed a couple of warnings (`UseZicond is turned off automatically. Turn it on with -XX:+UseZicond explicitly.`) when doing a native build on my P550 SBC which is not equipped with `Zicond` extension. I don't think that is expected? And I agree that it might be better to keep this option disabled by default and let users decide whether to enable it based on their cases. But what I see is that `UseZicond` will be auto-enabled through hwprobe [1] on my BPI-F3. So I am suggesting to not to do that in my previous comment. Make sense?

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp#L228

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24490#discussion_r2034572731
PR Review Comment: https://git.openjdk.org/jdk/pull/24490#discussion_r2034595744

From fyang at openjdk.org  Wed Apr  9 07:35:40 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 9 Apr 2025 07:35:40 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v2]
In-Reply-To: 
References: 
 
 
 <1pa1FDH5Z2quR3fE7o4qfZKwRrz8nXHbMSirSyiqhTw=.9c37d2a9-5b93-40dd-8b5a-a5822030ef48@github.com>
 <9R7U8cL4aSOayHQzaXoTGx0nXSXqdkO4ZomONZnM0Ao=.c1c90e1c-3085-4656-911d-23c407cff74d@github.com>
 
Message-ID: 

On Wed, 9 Apr 2025 06:31:55 GMT, Robbin Ehn  wrote:

> > > It's not some intermittently failure. The majority of them can't work as they use pstack, open core files, use PerfData, etc.. and expected it to be rv64. But core files, pstack are in host arch as we are running qemu-user. I can remove tests which timeouts and only keep test which simply can't work in qemu-user environment in this PR. Seems good?
> > 
> > 
> > Hi, That make sense to me. And it doesn't seem to me to be riscv-specific issue, but rather one with qemu-user. Maybe we should update the title and changes to reflect that? I sometimes see people testing with qemu for other CPU platforms as well like ppc, s390, etc. Guess they might be helped with this too.
> 
> Hey, thanks for considering. The default qemu /proc/cpu do not contain any information about this being qemu. And there is no standard way to find this out AFIAK. Some platforms have target specific /proc/cpu and put qemu in there, but it have no standard format. The whole proc -> uarch string -> jvm cpu string -> jtreg require is qemu/linux-user/riscv specific.

Ah, I see. But I guess it won't bite us if we can't parse `qemu` in /proc/cpuinfo? I am not familiar with how qemu-user works. Can I expect this to work at least for some other CPUs supported by the JVM?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2788626578

From vklang at openjdk.org  Wed Apr  9 08:06:33 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 9 Apr 2025 08:06:33 GMT
Subject: RFR: 8351927: Change VirtualThread implementation to use use FJP
 delayed task handling
In-Reply-To: 
References: <7vE97S4zy2S1vuRwEapE4k9ZScS6yTJBQWyKymjdc0g=.5551d6d6-68ad-446e-84c7-70fd57fa57a6@github.com>
 <64xe_dZIfIScyB_InbjJJn19DjAY_7qxmsB7FKKKIH4=.0c4ad76a-cbf8-475d-b3e8-6c2336ec1f29@github.com>
 
Message-ID: 

On Wed, 9 Apr 2025 05:56:28 GMT, Alan Bateman  wrote:

>> src/java.base/share/classes/java/lang/VirtualThread.java line 889:
>> 
>>> 887:     private void parkTimeoutExpired() {
>>> 888:         assert !VirtualThread.currentThread().isVirtual();
>>> 889:         if (!getAndSetParkPermit(true)
>> 
>> @AlanBateman Would it make sense to test whether the park-permit is false before the LOCK XCHG?
>
> It already does, no CAS if the current value is the new value.

I meant the park permit. :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24030#discussion_r2034736102

From rehn at openjdk.org  Wed Apr  9 08:09:42 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 9 Apr 2025 08:09:42 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v2]
In-Reply-To: 
References: 
 
 
 <1pa1FDH5Z2quR3fE7o4qfZKwRrz8nXHbMSirSyiqhTw=.9c37d2a9-5b93-40dd-8b5a-a5822030ef48@github.com>
 <9R7U8cL4aSOayHQzaXoTGx0nXSXqdkO4ZomONZnM0Ao=.c1c90e1c-3085-4656-911d-23c407cff74d@github.com>
 
 
Message-ID: 

On Wed, 9 Apr 2025 07:29:01 GMT, Fei Yang  wrote:

> > > > It's not some intermittently failure. The majority of them can't work as they use pstack, open core files, use PerfData, etc.. and expected it to be rv64. But core files, pstack are in host arch as we are running qemu-user. I can remove tests which timeouts and only keep test which simply can't work in qemu-user environment in this PR. Seems good?
> > > 
> > > 
> > > Hi, That make sense to me. And it doesn't seem to me to be riscv-specific issue, but rather one with qemu-user. Maybe we should update the title and changes to reflect that? I sometimes see people testing with qemu for other CPU platforms as well like ppc, s390, etc. Guess they might be helped with this too.
> > 
> > 
> > Hey, thanks for considering. The default qemu /proc/cpu do not contain any information about this being qemu. And there is no standard way to find this out AFIAK. Some platforms have target specific /proc/cpu and put qemu in there, but it have no standard format. The whole proc -> uarch string -> jvm cpu string -> jtreg require is qemu/linux-user/riscv specific.
> 
> Ah, I see. But I guess it won't bite us if we can't parse `qemu` in /proc/cpuinfo? I am not familiar with how qemu-user works. Can I expect this to work at least for some other CPUs supported by the JVM?

qemu-user, "uarch: qemu" in cpuinfo:
`[0.084s][info ][os,cpu] CPU: total 28 (initial active 28) qemu rv64 rvi rvm rva rvf rvd rvc rvv zba zbb zbs zfh zfhmin zvbc zvfh zicond`
Hence we know this is qemu-user (only qemu-user sets uarch to qemu on riscv).

`/proc/cpuinfo` do not contain uarch:
[0.053s][info ][os,cpu] CPU: total 8 (initial active 8) rv64 rvi rvm rva rvf rvd rvc zba zbb zbs zfh zfhmin zvfh zicond
We have no clue if this is emulated or on real hardware, tests will be executed.

Tests are only excluded if we know it's qemu-user.

Did that anwser your Q ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2788717608

From alanb at openjdk.org  Wed Apr  9 08:19:36 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 08:19:36 GMT
Subject: RFR: 8351927: Change VirtualThread implementation to use use FJP
 delayed task handling
In-Reply-To: 
References: <7vE97S4zy2S1vuRwEapE4k9ZScS6yTJBQWyKymjdc0g=.5551d6d6-68ad-446e-84c7-70fd57fa57a6@github.com>
 <64xe_dZIfIScyB_InbjJJn19DjAY_7qxmsB7FKKKIH4=.0c4ad76a-cbf8-475d-b3e8-6c2336ec1f29@github.com>
 
 
Message-ID: 

On Wed, 9 Apr 2025 08:03:44 GMT, Viktor Klang  wrote:

>> It already does, no CAS if the current value is the new value.
>
> I meant the park permit. :)

getAndSetParkPermit isn't changed in this PR. If the park permit is already granted then getAndSetParkPermit(true) doesn't do anything. More generally, parkTimeoutExpired is just a reduced unpark, only added so that we can do a lazy rather than internal submit for the less common case that the timeout expires.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24030#discussion_r2034760820

From vklang at openjdk.org  Wed Apr  9 08:46:36 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 9 Apr 2025 08:46:36 GMT
Subject: RFR: 8351927: Change VirtualThread implementation to use use FJP
 delayed task handling
In-Reply-To: <7vE97S4zy2S1vuRwEapE4k9ZScS6yTJBQWyKymjdc0g=.5551d6d6-68ad-446e-84c7-70fd57fa57a6@github.com>
References: <7vE97S4zy2S1vuRwEapE4k9ZScS6yTJBQWyKymjdc0g=.5551d6d6-68ad-446e-84c7-70fd57fa57a6@github.com>
Message-ID: 

On Thu, 13 Mar 2025 10:48:14 GMT, Alan Bateman  wrote:

> Follow up to JDK-8319447 to change the VirtualThread implementation to use FJP's delayed task handling.
> 
> The SPTE based implementation is not removed. It will continue to be used by tests. If custom schedulers are exposed in the future then they will use this implementation.
> 
> For timed-Object.wait, waitTimeoutExpired is changed to use lazySubmit to avoid signalling and increase the chance that the unparked virtual thread will continue on the current carrier. For timed-park, the timeout task is changed to reduced form of unpark that also uses lazySubmit, for the same reason.
> 
> `jcmd Thread.vthread_scheduler` is changed to no longer print the delay schedulers. Instead, the delayed task count will appear in the default scheduler output.

Marked as reviewed by vklang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24030#pullrequestreview-2752606260

From mli at openjdk.org  Wed Apr  9 08:51:36 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 9 Apr 2025 08:51:36 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 9 Apr 2025 06:41:51 GMT, Fei Yang  wrote:

>  Sorry for not being clear enough. I am suggesting this:

  if (UseZicond) {
    FLAG_SET_DEFAULT(ConditionalMoveLimit, 3);
  }


I think this depends on whether we should enable ConditionalMoveLimit based on `UseZicond`? So, I'll leave it until we have a dicision about the following discussion.

> Without Zicond extension, conditional moves composed by C2 are simply emulated with regular conditional branches on riscv, which I think is not good in respect of performance.

Yes, when Zicond is not supported (or turned off), C2 use the alternative path which is `branch + mv`.  When Zicond was introduced (https://github.com/openjdk/jdk/pull/22386), the rational behind it is that brach bring regression, but I think it's based on the fact that code size is the same. But in cmove case, the size is increased, and in particular when C2 unrolls a loop, it can increase the code size a lot, which is not good for cache. And the jmh test result shows that brach version is better than patch with Zicond and master with/wo Zicond in most of test cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24490#discussion_r2034819606

From djelinski at openjdk.org  Wed Apr  9 08:52:37 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 9 Apr 2025 08:52:37 GMT
Subject: RFR: 8351757: Test java/foreign/TestDeadlock.java#FileChannel_map
 timed out after passing
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 13:59:11 GMT, Per Minborg  wrote:

> This PR proposes to increase the timeout values for two tests.

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24511#pullrequestreview-2752626632

From mli at openjdk.org  Wed Apr  9 09:04:41 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 9 Apr 2025 09:04:41 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L [v2]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> Can you help to review this patch?
> On riscv, CMoveI/L already were implemented, but there are some gap:
> 1. CMoveI/L does not support comparison with float/double, corresponding tests are not turn on either.
> 2. Some optimization of C2 is not turned on, e.g. `Phi -> CMove -> min_max`.
> 3. lack of some corresponding performance tests.
> 
> Also there are some issue with current Zicond:
> 1. UseZicond is turned on automatically by hwprobe, but jmh tests show that it's not always bring benefit, in some situation it even brings regression, the reason is the generated code by Zicond is much larger than branch version, in particular when it's in a loop and unrolled.
> 
> This patch on riscv is to:
> 1. add CMoveI/L comparing float/double, and corresponding tests,
> 2. enable more C2 optimization,
> 3. add more benchmark tests,
> 4. turn off UseZicond by default.
> 
> Thanks!
> 
> ## Performance
> 
> ### MinMax
> test data
> 
> Benchmark | Mode | Cnt | Score - master | Score - master+UseZbb | Score - -master+UseZicond | Score - master+UseZicond+UseZbb | Score - cmovei | Score - cmovei+UseZbb | Score - cmovei+UseZicond | Score - cmovei+UseZicond+UseZbb | Error | Units | Opt (master/cmovei)
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> o.o.b.vm.compiler.IfMinMax.testReductionInt | avgt | 40 | 17152.075 | 17216.592 | 17272.493 | 17296.89 | 17127.844 | 17036.605 | 17299.333 | 17250.566 | 73.179 | ns/op | 1.001
> o.o.b.vm.compiler.IfMinMax.testReductionLong | avgt | 40 | 19770.828 | 19967.578 | 20268.905 | 20166.165 | 20065.552 | 20059.095 | 20161.914 | 20151.295 | 131.428 | ns/op | 0.985
> o.o.b.vm.compiler.IfMinMax.testSingleInt | avgt | 40 | 114.734 | 114.402 | 114.887 | 114.384 | 114.4 | 110.631 | 112.162 | 110.915 | 0.333 | ns/op | 1.003
> o.o.b.vm.compiler.IfMinMax.testSingleLong | avgt | 40 | 121.53 | 121.711 | 120.91 | 121.665 | 121.309 | 120.57 | 118.639 | 119.373 | 0.451 | ns/op | 1.002
> o.o.b.vm.compiler.IfMinMax.testVectorInt | avgt | 40 | 60130.165 | 60062.303 | 61839.776 | 61895.194 | 15887.398 | 15924.502 | 15874.835 | 15667.936 | 101.94 | ns/op | 3.785
> o.o.b.vm.compiler.IfMinMax.testVectorLong | avgt | 40 | 63855.379 | 6309...

Hamlin Li 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:

 - typo
 - Merge branch 'master' into cmoveil-v1
 - turn off flag Zicond by default
 - remove
 - initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24490/files
  - new: https://git.openjdk.org/jdk/pull/24490/files/0f013e7c..10f9adb0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24490&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24490&range=00-01

  Stats: 30103 lines in 808 files changed: 20231 ins; 7672 del; 2200 mod
  Patch: https://git.openjdk.org/jdk/pull/24490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24490/head:pull/24490

PR: https://git.openjdk.org/jdk/pull/24490

From mli at openjdk.org  Wed Apr  9 09:04:42 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 9 Apr 2025 09:04:42 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 8 Apr 2025 15:02:27 GMT, Feilong Jiang  wrote:

>> Hamlin Li 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:
>> 
>>  - typo
>>  - Merge branch 'master' into cmoveil-v1
>>  - turn off flag Zicond by default
>>  - remove
>>  - initial commit
>
> src/hotspot/cpu/riscv/riscv.ad line 9979:
> 
>> 9977: 
>> 9978:   format %{
>> 9979:     "CMove $dst, ($op1 $cop $op2), $dst, $src\t#@cmovI_cmpF\n\t"
> 
> Should be `CMoveI` too?

Yes, fixed. Thanks

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24490#discussion_r2034842102

From liach at openjdk.org  Wed Apr  9 09:06:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 09:06:44 GMT
Subject: RFR: 8352748: Remove com.sun.tools.classfile from the JDK
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 20:34:09 GMT, Chen Liang  wrote:

> With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.
> 
> Testing: built locally, running tier 1-3 tests
> 
> Don't know why, but GitHub is redundantly displaying changes that are already in #24212.

Tier 1-3 tests passed, only unrelated failure fixed by 8354088.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24528#issuecomment-2788873619

From tpushkin at openjdk.org  Wed Apr  9 09:06:44 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 9 Apr 2025 09:06:44 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v5]
In-Reply-To: 
References: 
 <9nX8O13jWi7qORu4uO-ppDmlph2W2lH1VVIKFP3-Gt8=.46545db1-b218-497d-b4ef-546410b09b9b@github.com>
 
Message-ID: 

On Tue, 8 Apr 2025 17:36:57 GMT, Ioi Lam  wrote:

>> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary scoping
>
> src/java.base/share/classes/jdk/internal/misc/CDS.java line 438:
> 
>> 436:             // class loader. Thus it is safe to delegate their loading to system class loader
>> 437:             // (our parent) - this is what the default implementation of loadClass() will do.
>> 438:             return defineClass(name, bytes, 0, bytes.length);
> 
> I didn't realize that `URLClassLoader` will by default delegate to `ClassLoader::getSystemClassLoader()`. How about rewording the comments like this to clarify?
> 
> 
> // defineClass() will internally invoke loadClass() to load supertypes of this unregistered class.
> // Any supertype S with the name SN must have already been loaded (enforced by the order
> // of classes in the classlist). In addition:
> // - if S is an unregistered class, S must have already been have been defined by the current class
> //   loader, and will be found by `this.findLoadedClass(SN)`
> // - if S is not an unregistered class, S must have already been defined by the built-in boot,
> //   platform, or system class loaders, and can be found by this.getParent().loadClass(SN, false)
> // See the implementation of ClassLoader::loadClass() for details.
> //
> // Therefore, we should resolve all supertypes to the expected ones as specified by the
> // super: and interfaces: attributes in the classlist. This
> // invariance is validated by the C++ function ClassListParser::load_class_from_source()
> assert getParent() == getSystemClassLoader();
> return defineClass(name, bytes, 0, bytes.length);

I've actually noticed a problem here. I assumed that registered classes are always loaded by JDK's built-in class loaders (bootstrap, `jdk.internal.loader.ClassLoaders$PlatformClassLoader` or `jdk.internal.loader.ClassLoaders$AppClassLoader`). But in reality when the system class loader is user-provided (via `-Dsystem.class.loader=`) classes loaded by it are still considered registered. This is a problem because such user-provided class loader may not delegate to real built-in class loaders.

For example:
- Let C= be a class C named N defined by class loader L
- Let AppL be the built-in system class loader and SysL be the user-provided system class loader
- Let U be an unregistered class which extends a registered 
- Let SysL be able to load a registered  when requested (i.e. SysL doesn't delegate when loading a class named S)
- When `UnregisteredClassLoader` will be loading U it will delegate the loading of its super named S to SysL and thus  will become a super of U instead of  ? this is an error (which will then be detected in `ClassListParser::load_class_from_source()` but still)

This won't be a problem if only classes loaded by the real built-in class loaders would be considered registered because such class loaders always delegate first (the 4th bullet above won't be possible), and thus it doesn't matter which of these loaders was used for delegation by the class loader which defined U.

This can't be fixed by just making `jdk.internal.loader.ClassLoaders$AppClassLoader` a parent of `UnregisteredClassLoader` and making `UnregisteredClassLoader.findClass(name)` return `getSystemClassLoader().loadClass(name)` because then the case when U extends  will not be handeled correctly ( will be used instead of ).

So it looks like I have to revert this delegation-based approach and use the old way.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2034846610

From liach at openjdk.org  Wed Apr  9 09:21:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 09:21:37 GMT
Subject: RFR: 8354121: Use an anonymous class rather than a lambda in
 AbstractMemorySegmentImpl::cleanupAction [v2]
In-Reply-To: 
References: 
 
Message-ID: <1i_AIJb7ci-qCTnznNfbcTQD39wBWkqKM4NdV_YQWCU=.ac9c74f0-f73a-41c1-839d-13f46e2df540@github.com>

On Tue, 8 Apr 2025 16:40:06 GMT, Per Minborg  wrote:

>> This PR proposes to use an anonymous class rather than a lambda in order to improve startup time.
>> 
>> We need to make sure the regression is fixed by this. It might be the case that the regression is there because [JDK-8347047](https://bugs.openjdk.org/browse/JDK-8347047) actually fixed an issue so that the segments could be collected by the GC.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment on anonymous class

@minborg Can we just use a local record to avoid accidental local captures (which caused the issue fixed by JDK-8347407)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24514#issuecomment-2788959662

From michaelm at openjdk.org  Wed Apr  9 10:04:47 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 9 Apr 2025 10:04:47 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v4]
In-Reply-To: 
References: 
Message-ID: <7QqAa8kPfdRpCCwiAleAk7v53UshuArCnUvMpRR0On8=.4646bb5b-5382-437c-9e7e-9e8513698d4a@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon 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 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Apply suggestions from code review
   
   from turbanoff review
   
   Co-authored-by: Andrey Turbanov 
 - doc + copyright update
 - remove file added by mistake
 - whitespace
 - moved test
 - Merge branch 'master' into 8348986-exceptions
 - update
 - update
 - ... and 7 more: https://git.openjdk.org/jdk/compare/f7fa05f5...f5501d18

-------------

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=03
  Stats: 1000 lines in 42 files changed: 767 ins; 104 del; 129 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From alanb at openjdk.org  Wed Apr  9 10:24:37 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 10:24:37 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v3]
In-Reply-To: 
References: 
 
Message-ID: <3Zk9YripITF8dslVfxe4NXy91mnMLLRjqJyDk48T6l4=.6644f577-685f-4c29-9db7-311f11b8e65a@github.com>

On Mon, 7 Apr 2025 21:07:36 GMT, Jan Lahoda  wrote:

>> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
>> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
>> - `java. ... .IO` is no longer automatically imported in any compilation unit
>> - the feature is finalized (i.e. no longer requires `--enable-preview`)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rewrite bits about charset decoding, removing mention of "internal objects."

src/java.base/share/classes/java/lang/IO.java line 47:

> 45:  * Decoding may buffer additional bytes beyond those that have been decoded to characters
> 46:  * returned to the application. After the first call to one of the {@code readln} methods,
> 47:  * any subsequent use of {@code System.in} results in unspecified behavior.

I wonder if we should add a note about mixing API usage into System.in too. There are tutorials and books that show examples build on System.in that will add buffering on that input source.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2035067290

From ihse at openjdk.org  Wed Apr  9 10:35:31 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 10:35:31 GMT
Subject: RFR: 8352748: Remove com.sun.tools.classfile from the JDK
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 20:34:09 GMT, Chen Liang  wrote:

> With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.
> 
> Testing: built locally, running tier 1-3 tests
> 
> Don't know why, but GitHub is redundantly displaying changes that are already in #24212.

Build changes look trivially fine.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24528#pullrequestreview-2753004950

From ayang at openjdk.org  Wed Apr  9 10:36:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 9 Apr 2025 10:36:44 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 4 Apr 2025 08:10:34 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 39 commits:
> 
>  - * missing file from merge
>  - 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 submit/8342382-card-table-instead-of-dcq
>  - * make young gen length revising independent of refinement thread
>      * use a service task
>      * both refinement control thread and young gen length revising use the same infrastructure to get the number of available bytes and determine the time to the next update
>  - * fix IR code generation tests that change due to barrier cost changes
>  - * factor out card table and refinement table merging into a single
>      method
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq3
>  - * obsolete G1UpdateBufferSize
>    
>    G1UpdateBufferSize has previously been used to size the refinement
>    buffers and impose a minimum limit on the number of cards per thread
>    that need to be pending before refinement starts.
>    
>    The former function is now obsolete with the removal of the dirty
>    card queues, the latter functionality has been taken over by the new
>    diagnostic option `G1PerThreadPendingCardThreshold`.
>    
>    I prefer to make this a diagnostic option is better than a product option
>    because it is something that is only necessary for some test cases to
>    produce some otherwise unwanted behavior (continuous refinement).
>    
>    CSR is pending.
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/41d4a0d7...1c5a669f

src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 170:

> 168:   }
> 169:   return result;
> 170: }

I see in `G1ConcurrentRefineThread::do_refinement`:

      // The yielding may have completed the task, check.
      if (!state.is_in_progress()) {

I wonder if it's simpler to use `is_in_progress` consistently to detect whether we should restart sweep, instead of `_sweep_start_epoch`.

src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 349:

> 347:   }
> 348: 
> 349:   bool has_sweep_rt_work = is_in_progress() && _state == State::SweepRT;

Why `is_in_progress()`?

src/hotspot/share/gc/g1/g1ConcurrentRefineStats.hpp line 79:

> 77: 
> 78:   void inc_cards_scanned(size_t increment = 1) { _cards_scanned += increment; }
> 79:   void inc_cards_clean(size_t increment = 1) { _cards_clean += increment; }

The sole caller always passes in arg, so no need for default-arg-value.

src/hotspot/share/gc/g1/g1ConcurrentRefineStats.hpp line 87:

> 85:   void add_atomic(G1ConcurrentRefineStats* other);
> 86: 
> 87:   G1ConcurrentRefineStats& operator+=(const G1ConcurrentRefineStats& other);

Seems that these operators are not used after this PR.

src/hotspot/share/gc/g1/g1ConcurrentRefineSweepTask.cpp line 83:

> 81:         break;
> 82:       }
> 83:       case G1RemSet::HasRefToOld : break; // Nothing special to do.

Why doesn't call `inc_cards_clean_again` in this case? The card is cleared also. (In fact, I don't get why this needs to a separate case from `NoInteresting`.)

src/hotspot/share/gc/g1/g1ConcurrentRefineSweepTask.cpp line 156:

> 154: 
> 155:       _refine_stats.inc_cards_scanned(claim.size());
> 156:       _refine_stats.inc_cards_clean(claim.size() - scanned);

I feel these two "scanned" mean sth diff; the local var should probably be sth like `num_dirty_cards`.

src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp line 207:

> 205: 
> 206:   if (!interrupted_by_gc) {
> 207:     state.add_yield_duration(G1CollectedHeap::heap()->safepoint_duration() - synchronize_duration_at_sweep_start);

I think this is recorded to later calculate actual refine-time, i.e. sweep-time - yield-time. However, why can't yield-duration be recorded in this refine-control-thread directly --  accumulation of `jlong yield_duration = os::elapsed_counter() - yield_start`. I feel that is easier to reason than going through g1heap.

src/hotspot/share/gc/g1/g1ReviseYoungListTargetLengthTask.cpp line 75:

> 73:   {
> 74:     MutexLocker x(G1ReviseYoungLength_lock, Mutex::_no_safepoint_check_flag);
> 75:     G1Policy* p = g1h->policy();

Can probably use the existing `policy`.

src/hotspot/share/gc/g1/g1ReviseYoungListTargetLengthTask.cpp line 88:

> 86: }
> 87: 
> 88: G1ReviseYoungLengthTargetLengthTask::G1ReviseYoungLengthTargetLengthTask(const char* name) :

I wonder if the class name can be shortened a bit, sth like `G1ReviseYoungLengthTask`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2033251162
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2033222407
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2033929489
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2033975054
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2033934399
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2033910496
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2032008908
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2029855278
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2029855435

From ihse at openjdk.org  Wed Apr  9 10:38:42 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 10:38:42 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v4]
In-Reply-To: 
References: 
 
Message-ID: <14ZPPDXO-VOJwlTuN934jfJF1-_yGlfH8pEQyHQh9QA=.b80aa673-4cb9-410e-b489-039aa6506bcb@github.com>

On Mon, 7 Apr 2025 13:35:57 GMT, Severin Gehwolf  wrote:

>> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
>> 
>> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
>> 
>> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
>> 2. For those files the hash sum checks are skipped.
>> 
>> **Testing**
>> 
>> - [x] GHA
>> - [x] `jdk/tools/jlink` jtreg tests (also on [GHA](https://github.com/jerboaa/jdk/actions/runs/14308729271))
>> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review v2

make/modules/jdk.jlink/Java.gmk line 28:

> 26: ################################################################################
> 27: 
> 28: COPY += upgrade_files_java.base

Any chance you can give this file a different name? It looks like it has extension `.base`. Maybe `upgrade_files_java.base.txt`, and then we can have a more general pattern of `*.txt`? Or maybe it should really be a properties file, to clearly indicate the nature of the file?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2035088155

From alanb at openjdk.org  Wed Apr  9 10:39:43 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 10:39:43 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v3]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Mon, 7 Apr 2025 18:28:21 GMT, Stuart Marks  wrote:

>> Someone is bound to ask why the readln method throw but the println methods don't.
>
> The IOError was carried over from Console.readLine(), which throws IOError on error. Of course we're decoupled from Console now, but that was the original reason.
> 
> My guess is that Console methods throw IOError because (a) they didn't want to make everybody catch IOException, (b) they didn't want to maintain an internal error state like PrintStream, and (c) they wanted to throw a throwable whose type conveyed the meaning that it wasn't expected to be handled. IOError and Console were both added in JDK 1.6. Maybe that reasoning still applies here.
> 
> UncheckedIOException wasn't added until JDK 1.8. Note also that UncheckedIOException has a cause of IOException, so it can't arise from some other throwable. This was used in the previous implementation, where IOError was thrown if Console was null. That doesn't apply anymore, but IOError is still somewhat more flexible than UncheckedIOException in this regard.
> 
> I think we need to say something, implicitly or explicitly, about error handling. Note that PrintStream has this internal error state so output is covered already. For input it seems like IOError is reasonable, but maybe there's a better choice.

The readln methods handle malformed-input and unmappable-character errors by dropping, and using a replacement value. So erroneous input doesn't throw IOError with a CharacterCodingException as the cause.

System.in.close() would a be wild thing to do, but a case where readln would throw IOError.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2035089368

From duke at openjdk.org  Wed Apr  9 10:44:02 2025
From: duke at openjdk.org (kabutz)
Date: Wed, 9 Apr 2025 10:44:02 GMT
Subject: RFR: 8354076: LinkedBlockingDeque offer() creates nodes even if
 capacity has been reached
Message-ID: 

In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking.

In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field.

Our suggestion is to make count volatile, and then exiting early from poll() and offer()

-------------

Commit messages:
 - Made code consistent with JavaDoc for only creating nodes if there is space in the LBD.

Changes: https://git.openjdk.org/jdk/pull/24521/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24521&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354076
  Stats: 47 lines in 1 file changed: 18 ins; 16 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/24521.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24521/head:pull/24521

PR: https://git.openjdk.org/jdk/pull/24521

From duke at openjdk.org  Wed Apr  9 10:45:54 2025
From: duke at openjdk.org (kabutz)
Date: Wed, 9 Apr 2025 10:45:54 GMT
Subject: RFR: 8354111: JavaDoc states that Iterator.remove() is linear in the
 LinkedBlockingDeque
Message-ID: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>

One of the features of the LinkedBlockingDeque is that it is a doubly-linked node queue, with pointers in each node to "prev" and "next", which allows remove() in the Iterator to remove the node in constant time. However, in the JavaDoc of the class, it lists Iterator.remove() as an example of a method that takes linear time.

-------------

Commit messages:
 - Fixed JavaDoc mistake - Iterator.remove() runs in constant time in the doubly-linked LBD

Changes: https://git.openjdk.org/jdk/pull/24500/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24500&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354111
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24500.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24500/head:pull/24500

PR: https://git.openjdk.org/jdk/pull/24500

From duke at openjdk.org  Wed Apr  9 10:45:54 2025
From: duke at openjdk.org (kabutz)
Date: Wed, 9 Apr 2025 10:45:54 GMT
Subject: RFR: 8354111: JavaDoc states that Iterator.remove() is linear in
 the LinkedBlockingDeque
In-Reply-To: <_a3kBjM2gkqKENnZTd4cmG3jBqEvKzZ2dP-7OEpZCDw=.2d804a75-a7ff-4936-b50d-b07daaf5f9ac@github.com>
References: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
 <_a3kBjM2gkqKENnZTd4cmG3jBqEvKzZ2dP-7OEpZCDw=.2d804a75-a7ff-4936-b50d-b07daaf5f9ac@github.com>
Message-ID: <13qISV5pUqLGvixZN8h4RhNZ0kmF44tjWl4JVID2Y8I=.5afdaa11-35eb-4a21-a391-d822d72b85f0@github.com>

On Tue, 8 Apr 2025 16:19:13 GMT, Chen Liang  wrote:

>> One of the features of the LinkedBlockingDeque is that it is a doubly-linked node queue, with pointers in each node to "prev" and "next", which allows remove() in the Iterator to remove the node in constant time. However, in the JavaDoc of the class, it lists Iterator.remove() as an example of a method that takes linear time.
>
> FYI @kabutz you can log in to bugs.openjdk.org and create an issue for your patch. This issue can be noreg-doc, but will require a small CSR (which you can create and write, as you are already an author) as this touches specification text, for archival purpose.

Hi @liach I found another mistake in the JavaDoc - it states "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." - however, in the LBD they do create the nodes even if we have reached capacity. This comment was copied over from LBQ, but is not strictly speaking correct for LBD. We could change the code to reflect the comment, or remove that sentence. Which way should we proceed?

> Hi @liach I found another mistake in the JavaDoc - it states "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." - however, in the LBD they do create the nodes even if we have reached capacity. This comment was copied over from LBQ, but is not strictly speaking correct for LBD. We could change the code to reflect the comment, or remove that sentence. Which way should we proceed?

Actually scratch that - I'll propose a fix that seems to improve other issues as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24500#issuecomment-2787209541
PR Comment: https://git.openjdk.org/jdk/pull/24500#issuecomment-2787312914

From liach at openjdk.org  Wed Apr  9 10:45:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 10:45:54 GMT
Subject: RFR: 8354111: JavaDoc states that Iterator.remove() is linear in
 the LinkedBlockingDeque
In-Reply-To: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
References: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
Message-ID: <_a3kBjM2gkqKENnZTd4cmG3jBqEvKzZ2dP-7OEpZCDw=.2d804a75-a7ff-4936-b50d-b07daaf5f9ac@github.com>

On Tue, 8 Apr 2025 08:50:37 GMT, kabutz  wrote:

> One of the features of the LinkedBlockingDeque is that it is a doubly-linked node queue, with pointers in each node to "prev" and "next", which allows remove() in the Iterator to remove the node in constant time. However, in the JavaDoc of the class, it lists Iterator.remove() as an example of a method that takes linear time.

FYI @kabutz you can log in to bugs.openjdk.org and create an issue for your patch. This issue can be noreg-doc, but will require a small CSR (which you can create and write, as you are already an author) as this touches specification text, for archival purpose.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24500#issuecomment-2786993509

From alanb at openjdk.org  Wed Apr  9 10:49:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 10:49:34 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 7 Apr 2025 21:07:36 GMT, Jan Lahoda  wrote:

>> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
>> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
>> - `java. ... .IO` is no longer automatically imported in any compilation unit
>> - the feature is finalized (i.e. no longer requires `--enable-preview`)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rewrite bits about charset decoding, removing mention of "internal objects."

src/java.base/share/classes/java/lang/IO.java line 42:

> 40:  * {@code System.in} into characters. The charset used for decoding is specified by the
> 41:  * {@link System#getProperties stdin.encoding} property. If this property is not present,
> 42:  * or if the charset it names cannot be loaded, then UTF-8 is used instead.

stdout.encoding and stdin.encoding are specified (in System.getProperties) to lead to unspecified behavior if started with either property set to a value other than UTF-8. We should work through the issues of introducing stdin.encoding as soon as we can, esp. the redirect cases and whether there is use cases for setting any of these properties on the command line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2035104215

From duke at openjdk.org  Wed Apr  9 10:58:32 2025
From: duke at openjdk.org (kabutz)
Date: Wed, 9 Apr 2025 10:58:32 GMT
Subject: RFR: 8354138: LinkedBlockingDeque allows us to exceed size with
 addAll()
Message-ID: 

In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then add that chain in bulk to the existing nodes. We count the nodes in "int n" and then whilst holding the lock, we check that we haven't exceeded the capacity with "if (count + n <= capacity)". However, if we pass in a collection that has more than Integer.MAX_VALUE items in it, then we can overflow n, making it negative. Since "count + n" is also negative, we can add the chain to our last item, and thus we end up with a LinkedBlockingDeque with more than Integer.MAX_VALUE of items and a negative size(). stream().count() gives the correct number of items.

This happens both via the bulk add constructor LinkedBlockingDeque(Collection) and when we call addAll(Collection) directly.

In Java 8, they didn't have the clever addAll() method, and thus it failed immediately.

Here is some test code:


import java.util.*;
import java.util.concurrent.*;

// To see the issue, run with at least 90 GB of memory:
// -XX:+UnlockExperimentalVMOptions -Xmx90g -Xms90g -XX:+UseEpsilonGC -verbose:gc
// To verify the fix, run with at least 200 GB of memory:
// -XX:+UnlockExperimentalVMOptions -Xmx200g -Xms200g -XX:+UseEpsilonGC -verbose:gc
// To try on older versions of Java that don't have the EpsilonGC, you can use:
// -XX:+UseG1GC -verbose:gc -Xmx91g -Xms91g -XX:NewSize=89g
public class NegativeSizedLinkedBlockingDeque {
    public static void main(String... args) {
        HUUUGECollection list = new HUUUGECollection(Integer.MAX_VALUE + 1L);
        LinkedBlockingDeque lbd = new LinkedBlockingDeque<>(10);
        lbd.addAll(list);
        System.out.println("lbd.size() = " + lbd.size());
        System.out.println(lbd.stream().count());
    }

    public static class HUUUGECollection extends AbstractCollection {
        private final long size;

        public HUUUGECollection(long size) {
            this.size = size;
        }

        @Override
        public int size() {
            return size < Integer.MAX_VALUE ? (int) size : Integer.MAX_VALUE;
        }

        @Override
        public Iterator iterator() {
            return new Iterator() {
                private long count = 0;

                public boolean hasNext() {
                    return count < size;
                }

                public Integer next() {
                    if (!hasNext()) throw new NoSuchElementException();
                    count++;
                    return 42;
                }
            };
        }
    }
}


Output is:


heinz$ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -verbose:gc -Xmx90g -Xms90g tjsn/ideas2025/juc/NegativeSizedLinkedBlockingDeque
[0.004s][info][gc] Using Epsilon
[0.005s][warning][gc,init] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups
[0.668s][info   ][gc     ] Heap: 92160M reserved, 92160M (100.00%) committed, 4610M (5.00%) used
[1.321s][info   ][gc     ] Heap: 92160M reserved, 92160M (100.00%) committed, 9218M (10.00%) used
[1.962s][info   ][gc     ] Heap: 92160M reserved, 92160M (100.00%) committed, 13826M (15.00%) used
[2.626s][info   ][gc     ] Heap: 92160M reserved, 92160M (100.00%) committed, 18434M (20.00%) used
[3.283s][info   ][gc     ] Heap: 92160M reserved, 92160M (100.00%) committed, 23042M (25.00%) used
[3.934s][info   ][gc     ] Heap: 92160M reserved, 92160M (100.00%) committed, 27650M (30.00%) used
[4.602s][info   ][gc     ] Heap: 92160M reserved, 92160M (100.00%) committed, 32258M (35.00%) used
[5.253s][info   ][gc     ] Heap: 92160M reserved, 92160M (100.00%) committed, 36866M (40.00%) used
[5.907s][info   ][gc     ] Heap: 92160M reserved, 92160M (100.00%) committed, 41474M (45.00%) used
[6.577s][info   ][gc     ] Heap: 92160M reserved, 92160M (100.00%) committed, 46082M (50.00%) used
[7.228s][info   ][gc     ] Heap: 92160M reserved, 92160M (100.00%) committed, 50690M (55.00%) used
[7.884s][info   ][gc     ] Heap: 92160M reserved, 92160M (100.00%) committed, 55298M (60.00%) used
[8.526s][info   ][gc     ] Heap: 92160M reserved, 92160M (100.00%) committed, 59906M (65.00%) used
[9.179s][info   ][gc     ] Heap: 92160M reserved, 92160M (100.00%) committed, 64514M (70.00%) used
[10.282s][info   ][gc     ] Heap: 92160M reserved, 92160M (100.00%) committed, 69122M (75.00%) used
[11.096s][info   ][gc     ] Heap: 92160M reserved, 92160M (100.00%) committed, 73730M (80.00%) used
[11.957s][info   ][gc     ] Heap: 92160M reserved, 92160M (100.00%) committed, 78338M (85.00%) used
lbd.size() = -2147483648
2147483648
[27.619s][info   ][gc     ] Heap: 92160M reserved, 92160M (100.00%) committed, 81942M (88.91%) used


This has been submitted as a bug - internal review ID : 9078362.

-------------

Commit messages:
 - Clear the previously created chain to allow it to be GC'ed before calling the super.addAll() method
 - Fixed bug in addAll() that allowed overflow on LBD nodes

Changes: https://git.openjdk.org/jdk/pull/24538/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24538&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354138
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24538.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24538/head:pull/24538

PR: https://git.openjdk.org/jdk/pull/24538

From sgehwolf at openjdk.org  Wed Apr  9 11:41:36 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 9 Apr 2025 11:41:36 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v4]
In-Reply-To: <14ZPPDXO-VOJwlTuN934jfJF1-_yGlfH8pEQyHQh9QA=.b80aa673-4cb9-410e-b489-039aa6506bcb@github.com>
References: 
 
 <14ZPPDXO-VOJwlTuN934jfJF1-_yGlfH8pEQyHQh9QA=.b80aa673-4cb9-410e-b489-039aa6506bcb@github.com>
Message-ID: 

On Wed, 9 Apr 2025 10:36:03 GMT, Magnus Ihse Bursie  wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review v2
>
> make/modules/jdk.jlink/Java.gmk line 28:
> 
>> 26: ################################################################################
>> 27: 
>> 28: COPY += upgrade_files_java.base
> 
> Any chance you can give this file a different name? It looks like it has extension `.base`. Maybe `upgrade_files_java.base.txt`, and then we can have a more general pattern of `*.txt`? Or maybe it should really be a properties file, to clearly indicate the nature of the file?

Sure. It's not really a properties file (which assumes `key=value`). How about `upgrade_files_.conf`? Then the pattern could be `upgrade_files_*.conf`. Thoughts?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2035181858

From liach at openjdk.org  Wed Apr  9 11:45:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 11:45:24 GMT
Subject: RFR: 8354138: LinkedBlockingDeque allows us to exceed size with
 addAll()
In-Reply-To: 
References: 
Message-ID: 

On Wed, 9 Apr 2025 06:24:30 GMT, kabutz  wrote:

> In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then add that chain in bulk to the existing nodes. We count the nodes in "int n" and then whilst holding the lock, we check that we haven't exceeded the capacity with "if (count + n <= capacity)". However, if we pass in a collection that has more than Integer.MAX_VALUE items in it, then we can overflow n, making it negative. Since "count + n" is also negative, we can add the chain to our last item, and thus we end up with a LinkedBlockingDeque with more than Integer.MAX_VALUE of items and a negative size(). stream().count() gives the correct number of items.
> 
> This happens both via the bulk add constructor LinkedBlockingDeque(Collection) and when we call addAll(Collection) directly.
> 
> In Java 8, they didn't have the clever addAll() method, and thus it failed immediately.
> 
> Here is some test code:
> 
> 
> import java.util.*;
> import java.util.concurrent.*;
> 
> // To see the issue, run with at least 90 GB of memory:
> // -XX:+UnlockExperimentalVMOptions -Xmx90g -Xms90g -XX:+UseEpsilonGC -verbose:gc
> // To verify the fix, run with at least 200 GB of memory:
> // -XX:+UnlockExperimentalVMOptions -Xmx200g -Xms200g -XX:+UseEpsilonGC -verbose:gc
> // To try on older versions of Java that don't have the EpsilonGC, you can use:
> // -XX:+UseG1GC -verbose:gc -Xmx91g -Xms91g -XX:NewSize=89g
> public class NegativeSizedLinkedBlockingDeque {
>     public static void main(String... args) {
>         HUUUGECollection list = new HUUUGECollection(Integer.MAX_VALUE + 1L);
>         LinkedBlockingDeque lbd = new LinkedBlockingDeque<>(10);
>         lbd.addAll(list);
>         System.out.println("lbd.size() = " + lbd.size());
>         System.out.println(lbd.stream().count());
>     }
> 
>     public static class HUUUGECollection extends AbstractCollection {
>         private final long size;
> 
>         public HUUUGECollection(long size) {
>             this.size = size;
>         }
> 
>         @Override
>         public int size() {
>             return size < Integer.MAX_VALUE ? (int) size : Integer.MAX_VALUE;
>         }
> 
>         @Override
>         public Iterator iterator() {
>             return new Iterator() {
>                 private long count = 0;
> 
>                 public boolean hasNext() {
>                     return count < size;
>                 }
> 
>                 public Integer next() {
>                     if (!hasNext()) throw new NoSuchElementException();
>                     count++;
>                     return 42;
>   ...

Hi @kabutz, I believe you can create issues on JBS (bugs.openjdk.org) directly without going thorough bugs.java.com - as an author in OpenJDK census, you have an account associated with your email, and you can log in to the JBS at https://id.openjdk.org/console/login?backUrl=https://bugs.openjdk.org and from there, you can create or edit issues or CSRs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24538#issuecomment-2789402400

From ihse at openjdk.org  Wed Apr  9 11:45:30 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 11:45:30 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v4]
In-Reply-To: 
References: 
 
 <14ZPPDXO-VOJwlTuN934jfJF1-_yGlfH8pEQyHQh9QA=.b80aa673-4cb9-410e-b489-039aa6506bcb@github.com>
 
Message-ID: 

On Wed, 9 Apr 2025 11:38:25 GMT, Severin Gehwolf  wrote:

>> make/modules/jdk.jlink/Java.gmk line 28:
>> 
>>> 26: ################################################################################
>>> 27: 
>>> 28: COPY += upgrade_files_java.base
>> 
>> Any chance you can give this file a different name? It looks like it has extension `.base`. Maybe `upgrade_files_java.base.txt`, and then we can have a more general pattern of `*.txt`? Or maybe it should really be a properties file, to clearly indicate the nature of the file?
>
> Sure. It's not really a properties file (which assumes `key=value`). How about `upgrade_files_.conf`? Then the pattern could be `upgrade_files_*.conf`. Thoughts?

Yeah, my comment was meant more like "maybe you should turn it into a proper properties file, by introducing a key name". But maybe that's just silly and overkill.

`.conf` sounds fine, I guess.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2035187744

From rcastanedalo at openjdk.org  Wed Apr  9 12:03:49 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 9 Apr 2025 12:03:49 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: 
References: 
 
Message-ID: <8noWoU1cd2y4EjjK3QZGMLacPC9gkrwn5Ns3XbQbppI=.74de0b05-b8da-417f-8096-de98d7a3d815@github.com>

On Fri, 4 Apr 2025 08:10:34 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 39 commits:
> 
>  - * missing file from merge
>  - 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 submit/8342382-card-table-instead-of-dcq
>  - * make young gen length revising independent of refinement thread
>      * use a service task
>      * both refinement control thread and young gen length revising use the same infrastructure to get the number of available bytes and determine the time to the next update
>  - * fix IR code generation tests that change due to barrier cost changes
>  - * factor out card table and refinement table merging into a single
>      method
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq3
>  - * obsolete G1UpdateBufferSize
>    
>    G1UpdateBufferSize has previously been used to size the refinement
>    buffers and impose a minimum limit on the number of cards per thread
>    that need to be pending before refinement starts.
>    
>    The former function is now obsolete with the removal of the dirty
>    card queues, the latter functionality has been taken over by the new
>    diagnostic option `G1PerThreadPendingCardThreshold`.
>    
>    I prefer to make this a diagnostic option is better than a product option
>    because it is something that is only necessary for some test cases to
>    produce some otherwise unwanted behavior (continuous refinement).
>    
>    CSR is pending.
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/41d4a0d7...1c5a669f

Hi Thomas, great simplification and encouraging results! I reviewed the compiler-related parts of the changeset, including x64 and aarch64 changes.

src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp line 246:

> 244:     __ cbz(new_val, done);
> 245:   }
> 246:   // Storing region crossing non-null, is card young?

Suggestion:

  // Storing region crossing non-null.

src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 101:

> 99: }
> 100: 
> 101: void G1BarrierSetAssembler::gen_write_ref_array_post_barrier(MacroAssembler* masm, DecoratorSet decorators,

Have you measured the performance impact of inlining this assembly code instead of resorting to a runtime call as done before? Is it worth the maintenance cost (for every platform), risk of introducing bugs, etc.?

src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 145:

> 143: 
> 144:   __ bind(is_clean_card);
> 145:   // Card was clean. Dirty card and go to next..

This code seems unreachable if `!UseCondCardMark`, meaning we only dirty cards here if `UseCondCardMark` is enabled. Is that intentional?

src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 319:

> 317:                                             const Register thread,
> 318:                                             const Register tmp1,
> 319:                                             const Register tmp2,

Since `tmp2` is not needed in the x64 post-barrier, I suggest not passing it around for this platform, for simplicity and also to make optimization opportunities more visible in the future. Here is my suggestion: https://github.com/robcasloz/jdk/commit/855ec8df4a641f8c491c5c09acea3ee434b7e230, feel free to merge if you agree.

src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp line 38:

> 36: #include "c1/c1_LIRAssembler.hpp"
> 37: #include "c1/c1_MacroAssembler.hpp"
> 38: #endif // COMPILER1

I suggest removing the conditional compilation directives and grouping these includes together with the above `c1` ones.

src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp line 147:

> 145:     state->do_input(_thread);
> 146: 
> 147:     // Use temp registers to ensure these they use different registers.

Suggestion:

    // Use temps to enforce different registers.

src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 307:

> 305:              + 6  // same region check: Uncompress (new_val) oop, xor, shr, (cmp), jmp
> 306:              + 4  // new_val is null check
> 307:              + 4; // card not clean check.

It probably does not affect the unrolling heuristics too much, but you may want to make the last cost component conditional on `UseCondCardMark`.

src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 396:

> 394:   bool needs_liveness_data(const MachNode* mach) const {
> 395:     return G1BarrierStubC2::needs_pre_barrier(mach) ||
> 396:            G1BarrierStubC2::needs_post_barrier(mach);

Suggestion:

    // Liveness data is only required to compute registers that must be
    // preserved across the runtime call in the pre-barrier stub.
    return G1BarrierStubC2::needs_pre_barrier(mach);

src/hotspot/share/gc/g1/g1BarrierSet.hpp line 56:

> 54: //
> 55: // The refinement threads mark cards in the current collection set specially on the
> 56: // card table - this is fine wrt to synchronization with the mutator, because at

Suggestion:

// card table - this is fine wrt synchronization with the mutator, because at

test/hotspot/jtreg/compiler/gcbarriers/TestG1BarrierGeneration.java line 521:

> 519:         phase = CompilePhase.FINAL_CODE)
> 520:     @IR(counts = {IRNode.COUNTED_LOOP, "2"},
> 521:         phase = CompilePhase.FINAL_CODE)

I suggest to remove this extra IR check to avoid over-specifying the expected loop shape. For example, running this test with loop unrolling disabled (`-XX:LoopUnrollLimit=0`) would now fail because only one counted loop would be found.

-------------

Changes requested by rcastanedalo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-2753154117
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035174209
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035175921
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035177738
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035183250
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035186980
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035192666
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035210464
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035196251
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035198219
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035201056

From duke at openjdk.org  Wed Apr  9 12:14:45 2025
From: duke at openjdk.org (kabutz)
Date: Wed, 9 Apr 2025 12:14:45 GMT
Subject: RFR: 8354111: JavaDoc states that Iterator.remove() is linear in
 the LinkedBlockingDeque
In-Reply-To: <_a3kBjM2gkqKENnZTd4cmG3jBqEvKzZ2dP-7OEpZCDw=.2d804a75-a7ff-4936-b50d-b07daaf5f9ac@github.com>
References: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
 <_a3kBjM2gkqKENnZTd4cmG3jBqEvKzZ2dP-7OEpZCDw=.2d804a75-a7ff-4936-b50d-b07daaf5f9ac@github.com>
Message-ID: 

On Tue, 8 Apr 2025 16:19:13 GMT, Chen Liang  wrote:

>> One of the features of the LinkedBlockingDeque is that it is a doubly-linked node queue, with pointers in each node to "prev" and "next", which allows remove() in the Iterator to remove the node in constant time. However, in the JavaDoc of the class, it lists Iterator.remove() as an example of a method that takes linear time.
>
> FYI @kabutz you can log in to bugs.openjdk.org and create an issue for your patch. This issue can be noreg-doc, but will require a small CSR (which you can create and write, as you are already an author) as this touches specification text, for archival purpose.

Added https://bugs.openjdk.org/browse/JDK-8354169 - not sure if that is what you meant @liach ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24500#issuecomment-2789488869

From liach at openjdk.org  Wed Apr  9 12:14:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 12:14:46 GMT
Subject: RFR: 8354111: JavaDoc states that Iterator.remove() is linear in
 the LinkedBlockingDeque
In-Reply-To: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
References: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
Message-ID: 

On Tue, 8 Apr 2025 08:50:37 GMT, kabutz  wrote:

> One of the features of the LinkedBlockingDeque is that it is a doubly-linked node queue, with pointers in each node to "prev" and "next", which allows remove() in the Iterator to remove the node in constant time. However, in the JavaDoc of the class, it lists Iterator.remove() as an example of a method that takes linear time.

Yep, that's how we can create issues; we already have 8354111, you can close one of them as a duplicate of the other as we will just have one patch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24500#issuecomment-2789493649

From duke at openjdk.org  Wed Apr  9 12:18:46 2025
From: duke at openjdk.org (kabutz)
Date: Wed, 9 Apr 2025 12:18:46 GMT
Subject: RFR: 8354138: LinkedBlockingDeque allows us to exceed size with
 addAll()
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 9 Apr 2025 11:43:16 GMT, Chen Liang  wrote:

>> In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then add that chain in bulk to the existing nodes. We count the nodes in "int n" and then whilst holding the lock, we check that we haven't exceeded the capacity with "if (count + n <= capacity)". However, if we pass in a collection that has more than Integer.MAX_VALUE items in it, then we can overflow n, making it negative. Since "count + n" is also negative, we can add the chain to our last item, and thus we end up with a LinkedBlockingDeque with more than Integer.MAX_VALUE of items and a negative size(). stream().count() gives the correct number of items.
>> 
>> This happens both via the bulk add constructor LinkedBlockingDeque(Collection) and when we call addAll(Collection) directly.
>> 
>> In Java 8, they didn't have the clever addAll() method, and thus it failed immediately.
>> 
>> Here is some test code:
>> 
>> 
>> import java.util.*;
>> import java.util.concurrent.*;
>> 
>> // To see the issue, run with at least 90 GB of memory:
>> // -XX:+UnlockExperimentalVMOptions -Xmx90g -Xms90g -XX:+UseEpsilonGC -verbose:gc
>> // To verify the fix, run with at least 200 GB of memory:
>> // -XX:+UnlockExperimentalVMOptions -Xmx200g -Xms200g -XX:+UseEpsilonGC -verbose:gc
>> // To try on older versions of Java that don't have the EpsilonGC, you can use:
>> // -XX:+UseG1GC -verbose:gc -Xmx91g -Xms91g -XX:NewSize=89g
>> public class NegativeSizedLinkedBlockingDeque {
>>     public static void main(String... args) {
>>         HUUUGECollection list = new HUUUGECollection(Integer.MAX_VALUE + 1L);
>>         LinkedBlockingDeque lbd = new LinkedBlockingDeque<>(10);
>>         lbd.addAll(list);
>>         System.out.println("lbd.size() = " + lbd.size());
>>         System.out.println(lbd.stream().count());
>>     }
>> 
>>     public static class HUUUGECollection extends AbstractCollection {
>>         private final long size;
>> 
>>         public HUUUGECollection(long size) {
>>             this.size = size;
>>         }
>> 
>>         @Override
>>         public int size() {
>>             return size < Integer.MAX_VALUE ? (int) size : Integer.MAX_VALUE;
>>         }
>> 
>>         @Override
>>         public Iterator iterator() {
>>             return new Iterator() {
>>                 private long count = 0;
>> 
>>                 public boolean hasNext() {
>>                     return count < size;
>>                 }
>> 
>>                 public Integer next() {
>>                     if (!hasNext()...
>
> Hi @kabutz, I believe you can create issues on JBS (bugs.openjdk.org) directly without going thorough bugs.java.com - as an author in OpenJDK census, you have an account associated with your email, and you can log in to the JBS at https://id.openjdk.org/console/login?backUrl=https://bugs.openjdk.org and from there, you can create or edit issues or CSRs.

Thanks @liach, I'm just not sure about all the fields in the OpenJDK census - will try do that next time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24538#issuecomment-2789503132

From duke at openjdk.org  Wed Apr  9 12:27:50 2025
From: duke at openjdk.org (kabutz)
Date: Wed, 9 Apr 2025 12:27:50 GMT
Subject: RFR: 8354111: JavaDoc states that Iterator.remove() is linear in
 the LinkedBlockingDeque
In-Reply-To: 
References: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
 
Message-ID: 

On Wed, 9 Apr 2025 12:12:02 GMT, Chen Liang  wrote:

>> One of the features of the LinkedBlockingDeque is that it is a doubly-linked node queue, with pointers in each node to "prev" and "next", which allows remove() in the Iterator to remove the node in constant time. However, in the JavaDoc of the class, it lists Iterator.remove() as an example of a method that takes linear time.
>
> Yep, that's how we can create issues; we already have 8354111, you can close one of them as a duplicate of the other as we will just have one patch.

Ok, I've filled in the details for the CSR for 8354111. Sorry for all the additional work @liach

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24500#issuecomment-2789530968

From rriggs at openjdk.org  Wed Apr  9 12:28:31 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 9 Apr 2025 12:28:31 GMT
Subject: RFR: 8351757: Test java/foreign/TestDeadlock.java#FileChannel_map
 timed out after passing
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 13:59:11 GMT, Per Minborg  wrote:

> This PR proposes to increase the timeout values for two tests.

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24511#pullrequestreview-2753292005

From liach at openjdk.org  Wed Apr  9 12:39:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 12:39:30 GMT
Subject: RFR: 8354111: JavaDoc states that Iterator.remove() is linear in
 the LinkedBlockingDeque
In-Reply-To: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
References: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
Message-ID: 

On Tue, 8 Apr 2025 08:50:37 GMT, kabutz  wrote:

> One of the features of the LinkedBlockingDeque is that it is a doubly-linked node queue, with pointers in each node to "prev" and "next", which allows remove() in the Iterator to remove the node in constant time. However, in the JavaDoc of the class, it lists Iterator.remove() as an example of a method that takes linear time.

Thanks! FYI the CSR requires a few more fields to be filled - see https://wiki.openjdk.org/display/csr/Fields+of+a+CSR+Request for details. You can click the "Edit" button on the CSR to see all those fields; many are not available in the browsing view.

In addition, I think you can mention that this constant time is already the preexisting behavior and indicate there is no (minimal, "None" means the field is not filled) compatibility risk.

Once you have filled all required or needed fields (In particular, don't forget about fix version of 25 and scope of SE), I can review the CSR and you can proceed to move it to "Finalized" (Click on the "Draft" button)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24500#issuecomment-2789559354

From duke at openjdk.org  Wed Apr  9 12:39:32 2025
From: duke at openjdk.org (kabutz)
Date: Wed, 9 Apr 2025 12:39:32 GMT
Subject: RFR: 8354111: JavaDoc states that Iterator.remove() is linear in
 the LinkedBlockingDeque
In-Reply-To: 
References: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
 
Message-ID: 

On Wed, 9 Apr 2025 12:36:21 GMT, Chen Liang  wrote:

>> One of the features of the LinkedBlockingDeque is that it is a doubly-linked node queue, with pointers in each node to "prev" and "next", which allows remove() in the Iterator to remove the node in constant time. However, in the JavaDoc of the class, it lists Iterator.remove() as an example of a method that takes linear time.
>
> Thanks! FYI the CSR requires a few more fields to be filled - see https://wiki.openjdk.org/display/csr/Fields+of+a+CSR+Request for details. You can click the "Edit" button on the CSR to see all those fields; many are not available in the browsing view.
> 
> In addition, I think you can mention that this constant time is already the preexisting behavior and indicate there is no (minimal, "None" means the field is not filled) compatibility risk.
> 
> Once you have filled all required or needed fields (In particular, don't forget about fix version of 25 and scope of SE), I can review the CSR and you can proceed to move it to "Finalized" (Click on the "Draft" button)

> @liach JCheck configuration is invalid in the target branch of this pull request. Please issue this command again once the problem has been resolved.

Any idea what this is about @liach ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24500#issuecomment-2789559918

From alanb at openjdk.org  Wed Apr  9 12:39:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 12:39:48 GMT
Subject: Integrated: 8351927: Change VirtualThread implementation to use use
 FJP delayed task handling
In-Reply-To: <7vE97S4zy2S1vuRwEapE4k9ZScS6yTJBQWyKymjdc0g=.5551d6d6-68ad-446e-84c7-70fd57fa57a6@github.com>
References: <7vE97S4zy2S1vuRwEapE4k9ZScS6yTJBQWyKymjdc0g=.5551d6d6-68ad-446e-84c7-70fd57fa57a6@github.com>
Message-ID: 

On Thu, 13 Mar 2025 10:48:14 GMT, Alan Bateman  wrote:

> Follow up to JDK-8319447 to change the VirtualThread implementation to use FJP's delayed task handling.
> 
> The SPTE based implementation is not removed. It will continue to be used by tests. If custom schedulers are exposed in the future then they will use this implementation.
> 
> For timed-Object.wait, waitTimeoutExpired is changed to use lazySubmit to avoid signalling and increase the chance that the unparked virtual thread will continue on the current carrier. For timed-park, the timeout task is changed to reduced form of unpark that also uses lazySubmit, for the same reason.
> 
> `jcmd Thread.vthread_scheduler` is changed to no longer print the delay schedulers. Instead, the delayed task count will appear in the default scheduler output.

This pull request has now been integrated.

Changeset: 6c93ad42
Author:    Alan Bateman 
URL:       https://git.openjdk.org/jdk/commit/6c93ad42f38b49ea96155340c4b6bbedfcef2a90
Stats:     405 lines in 8 files changed: 332 ins; 41 del; 32 mod

8351927: Change VirtualThread implementation to use use FJP delayed task handling

Reviewed-by: vklang

-------------

PR: https://git.openjdk.org/jdk/pull/24030

From tschatzl at openjdk.org  Wed Apr  9 12:41:40 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 9 Apr 2025 12:41:40 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: <8noWoU1cd2y4EjjK3QZGMLacPC9gkrwn5Ns3XbQbppI=.74de0b05-b8da-417f-8096-de98d7a3d815@github.com>
References: 
 
 <8noWoU1cd2y4EjjK3QZGMLacPC9gkrwn5Ns3XbQbppI=.74de0b05-b8da-417f-8096-de98d7a3d815@github.com>
Message-ID: 

On Wed, 9 Apr 2025 11:35:26 GMT, Roberto Casta?eda Lozano  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 39 commits:
>> 
>>  - * missing file from merge
>>  - 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 submit/8342382-card-table-instead-of-dcq
>>  - * make young gen length revising independent of refinement thread
>>      * use a service task
>>      * both refinement control thread and young gen length revising use the same infrastructure to get the number of available bytes and determine the time to the next update
>>  - * fix IR code generation tests that change due to barrier cost changes
>>  - * factor out card table and refinement table merging into a single
>>      method
>>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq3
>>  - * obsolete G1UpdateBufferSize
>>    
>>    G1UpdateBufferSize has previously been used to size the refinement
>>    buffers and impose a minimum limit on the number of cards per thread
>>    that need to be pending before refinement starts.
>>    
>>    The former function is now obsolete with the removal of the dirty
>>    card queues, the latter functionality has been taken over by the new
>>    diagnostic option `G1PerThreadPendingCardThreshold`.
>>    
>>    I prefer to make this a diagnostic option is better than a product option
>>    because it is something that is only necessary for some test cases to
>>    produce some otherwise unwanted behavior (continuous refinement).
>>    
>>    CSR is pending.
>>  - ... and 29 more: https://git.openjdk.org/jdk/compare/41d4a0d7...1c5a669f
>
> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 145:
> 
>> 143: 
>> 144:   __ bind(is_clean_card);
>> 145:   // Card was clean. Dirty card and go to next..
> 
> This code seems unreachable if `!UseCondCardMark`, meaning we only dirty cards here if `UseCondCardMark` is enabled. Is that intentional?

Great find!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035280909

From pminborg at openjdk.org  Wed Apr  9 12:47:40 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 9 Apr 2025 12:47:40 GMT
Subject: RFR: 8351757: Test java/foreign/TestDeadlock.java#FileChannel_map
 timed out after passing
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 13:59:11 GMT, Per Minborg  wrote:

> This PR proposes to increase the timeout values for two tests.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24511#issuecomment-2789578764

From pminborg at openjdk.org  Wed Apr  9 12:47:40 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 9 Apr 2025 12:47:40 GMT
Subject: Integrated: 8351757: Test
 java/foreign/TestDeadlock.java#FileChannel_map timed out after passing
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 13:59:11 GMT, Per Minborg  wrote:

> This PR proposes to increase the timeout values for two tests.

This pull request has now been integrated.

Changeset: f9d705b1
Author:    Per Minborg 
URL:       https://git.openjdk.org/jdk/commit/f9d705b17e5d90f7bc5f9759f692182bb4da3445
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8351757: Test java/foreign/TestDeadlock.java#FileChannel_map timed out after passing

Reviewed-by: djelinski, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/24511

From tschatzl at openjdk.org  Wed Apr  9 12:50:42 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 9 Apr 2025 12:50:42 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: <8noWoU1cd2y4EjjK3QZGMLacPC9gkrwn5Ns3XbQbppI=.74de0b05-b8da-417f-8096-de98d7a3d815@github.com>
References: 
 
 <8noWoU1cd2y4EjjK3QZGMLacPC9gkrwn5Ns3XbQbppI=.74de0b05-b8da-417f-8096-de98d7a3d815@github.com>
Message-ID: 

On Wed, 9 Apr 2025 11:34:09 GMT, Roberto Casta?eda Lozano  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 39 commits:
>> 
>>  - * missing file from merge
>>  - 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 submit/8342382-card-table-instead-of-dcq
>>  - * make young gen length revising independent of refinement thread
>>      * use a service task
>>      * both refinement control thread and young gen length revising use the same infrastructure to get the number of available bytes and determine the time to the next update
>>  - * fix IR code generation tests that change due to barrier cost changes
>>  - * factor out card table and refinement table merging into a single
>>      method
>>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq3
>>  - * obsolete G1UpdateBufferSize
>>    
>>    G1UpdateBufferSize has previously been used to size the refinement
>>    buffers and impose a minimum limit on the number of cards per thread
>>    that need to be pending before refinement starts.
>>    
>>    The former function is now obsolete with the removal of the dirty
>>    card queues, the latter functionality has been taken over by the new
>>    diagnostic option `G1PerThreadPendingCardThreshold`.
>>    
>>    I prefer to make this a diagnostic option is better than a product option
>>    because it is something that is only necessary for some test cases to
>>    produce some otherwise unwanted behavior (continuous refinement).
>>    
>>    CSR is pending.
>>  - ... and 29 more: https://git.openjdk.org/jdk/compare/41d4a0d7...1c5a669f
>
> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 101:
> 
>> 99: }
>> 100: 
>> 101: void G1BarrierSetAssembler::gen_write_ref_array_post_barrier(MacroAssembler* masm, DecoratorSet decorators,
> 
> Have you measured the performance impact of inlining this assembly code instead of resorting to a runtime call as done before? Is it worth the maintenance cost (for every platform), risk of introducing bugs, etc.?

I remember significant impact in some microbenchmark. It's also inlined in Parallel GC. I do not consider it a big issue wrt to maintenance - these things never really change, and the method is small and contained.
I will try to redo numbers.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035298557

From duke at openjdk.org  Wed Apr  9 12:56:38 2025
From: duke at openjdk.org (Zihao Lin)
Date: Wed, 9 Apr 2025 12:56:38 GMT
Subject: RFR: 8350462: MethodTypeForm.LF_INTERPRET can cache the MemberName
 instead [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 7 Apr 2025 19:16:11 GMT, Chen Liang  wrote:

>> OK, removed it.
>
> Now the index 6 is left unused in the LF cache array - we can leave it empty and renumber the cache indices when we add a new entry to cache.

Got it, thanks for the explanation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24468#discussion_r2035308887

From alanb at openjdk.org  Wed Apr  9 12:57:41 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 12:57:41 GMT
Subject: RFR: 8354111: JavaDoc states that Iterator.remove() is linear in
 the LinkedBlockingDeque
In-Reply-To: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
References: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
Message-ID: 

On Tue, 8 Apr 2025 08:50:37 GMT, kabutz  wrote:

> One of the features of the LinkedBlockingDeque is that it is a doubly-linked node queue, with pointers in each node to "prev" and "next", which allows remove() in the Iterator to remove the node in constant time. However, in the JavaDoc of the class, it lists Iterator.remove() as an example of a method that takes linear time.

This seems to date from JDK 6 when LBD was added. The list of methods in the class description that don't run in constant time isn't fully exhaustive, but doing a CSR would do no harm here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24500#issuecomment-2789611312

From pminborg at openjdk.org  Wed Apr  9 13:02:08 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 9 Apr 2025 13:02:08 GMT
Subject: RFR: 8354121: Use an anonymous class rather than a lambda in
 AbstractMemorySegmentImpl::cleanupAction [v3]
In-Reply-To: 
References: 
Message-ID: <6CmGQQA7cryhgsy3GSW2QkmqjAWugJR6VHhcXcphXEo=.2599bdac-9f84-4b28-a582-5acb387e3180@github.com>

> This PR proposes to use an anonymous class rather than a lambda in order to improve startup time.
> 
> We need to make sure the regression is fixed by this. It might be the case that the regression is there because [JDK-8347047](https://bugs.openjdk.org/browse/JDK-8347047) actually fixed an issue so that the segments could be collected by the GC.

Per Minborg 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:

 - Use a record instead of anno class
 - Merge branch 'master' into ms-reinterpret-remove-lambda
 - Add comment on anonymous class
 - Replace lambda with anonymous class

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24514/files
  - new: https://git.openjdk.org/jdk/pull/24514/files/49c4b352..730c064f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24514&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24514&range=01-02

  Stats: 8587 lines in 274 files changed: 5246 ins; 2360 del; 981 mod
  Patch: https://git.openjdk.org/jdk/pull/24514.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24514/head:pull/24514

PR: https://git.openjdk.org/jdk/pull/24514

From liach at openjdk.org  Wed Apr  9 13:04:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 13:04:43 GMT
Subject: RFR: 8354111: JavaDoc states that Iterator.remove() is linear in
 the LinkedBlockingDeque
In-Reply-To: 
References: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
 
Message-ID: <-0Gd_7ggPoLDE5Lzm093_ZugR8QCvwZc0estsADA0Vw=.b80ff540-8368-499f-b5df-d7798235299c@github.com>

On Wed, 9 Apr 2025 12:36:21 GMT, Chen Liang  wrote:

>> One of the features of the LinkedBlockingDeque is that it is a doubly-linked node queue, with pointers in each node to "prev" and "next", which allows remove() in the Iterator to remove the node in constant time. However, in the JavaDoc of the class, it lists Iterator.remove() as an example of a method that takes linear time.
>
> Thanks! FYI the CSR requires a few more fields to be filled - see https://wiki.openjdk.org/display/csr/Fields+of+a+CSR+Request for details. You can click the "Edit" button on the CSR to see all those fields; many are not available in the browsing view.
> 
> In addition, I think you can mention that this constant time is already the preexisting behavior and indicate there is no (minimal, "None" means the field is not filled) compatibility risk.
> 
> Once you have filled all required or needed fields (In particular, don't forget about fix version of 25 and scope of SE), I can review the CSR and you can proceed to move it to "Finalized" (Click on the "Draft" button)

> Any idea what this is about @liach ?

I assume this is a rare glitch in the bot. This PR has the csr label and is in a right state.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24500#issuecomment-2789630012

From rgiulietti at openjdk.org  Wed Apr  9 13:10:12 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 9 Apr 2025 13:10:12 GMT
Subject: RFR: 8351462: Improve robustness of String concatenation
Message-ID: <0M-TVwJNfVFGM37oYEQHrntixxa3YK-mIi2dLLOpURI=.f4d7fe87-5d41-4440-beb4-deb997a0e871@github.com>

Early detection of an `int` overflow in `StringConcatHelper` improves robustness of `StringConcatFactory`.

-------------

Commit messages:
 - 8351462: Improve robustness of String concatenation

Changes: https://git.openjdk.org/jdk/pull/24546/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24546&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351462
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24546.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24546/head:pull/24546

PR: https://git.openjdk.org/jdk/pull/24546

From sgehwolf at openjdk.org  Wed Apr  9 13:22:32 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 9 Apr 2025 13:22:32 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v4]
In-Reply-To: 
References: 
 
 <14ZPPDXO-VOJwlTuN934jfJF1-_yGlfH8pEQyHQh9QA=.b80aa673-4cb9-410e-b489-039aa6506bcb@github.com>
 
 
Message-ID: <-WHxsRmElMyplPKGDTvavb-Bv0v-dJGqIYshTTgKvfY=.33c0a93e-a30d-4381-8167-5c9788a8a80d@github.com>

On Wed, 9 Apr 2025 11:42:31 GMT, Magnus Ihse Bursie  wrote:

>> Sure. It's not really a properties file (which assumes `key=value`). How about `upgrade_files_.conf`? Then the pattern could be `upgrade_files_*.conf`. Thoughts?
>
> Yeah, my comment was meant more like "maybe you should turn it into a proper properties file, by introducing a key name". But maybe that's just silly and overkill.
> 
> `.conf` sounds fine, I guess.

Thanks. Making this a properties file is overkill and feels like fitting a square peg into a round hole. I'll make those `*.conf` files then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2035358134

From duke at openjdk.org  Wed Apr  9 13:24:25 2025
From: duke at openjdk.org (kabutz)
Date: Wed, 9 Apr 2025 13:24:25 GMT
Subject: RFR: 8354111: JavaDoc states that Iterator.remove() is linear in
 the LinkedBlockingDeque
In-Reply-To: 
References: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
 
Message-ID: 

On Wed, 9 Apr 2025 12:36:21 GMT, Chen Liang  wrote:

> Thanks! FYI the CSR requires a few more fields to be filled - see https://wiki.openjdk.org/display/csr/Fields+of+a+CSR+Request for details. You can click the "Edit" button on the CSR to see all those fields; many are not available in the browsing view.
> 
> In addition, I think you can mention that this constant time is already the preexisting behavior and indicate there is no (minimal, "None" means the field is not filled) compatibility risk.
> 
> Once you have filled all required or needed fields (In particular, don't forget about fix version of 25 and scope of SE), I can review the CSR and you can proceed to move it to "Finalized" (Click on the "Draft" button)

Please let me know once I can set it to "Finalized". I hope I filled everything in correctly ...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24500#issuecomment-2789687511

From liach at openjdk.org  Wed Apr  9 13:28:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 13:28:32 GMT
Subject: RFR: 8351462: Improve robustness of String concatenation
In-Reply-To: <0M-TVwJNfVFGM37oYEQHrntixxa3YK-mIi2dLLOpURI=.f4d7fe87-5d41-4440-beb4-deb997a0e871@github.com>
References: <0M-TVwJNfVFGM37oYEQHrntixxa3YK-mIi2dLLOpURI=.f4d7fe87-5d41-4440-beb4-deb997a0e871@github.com>
Message-ID: 

On Wed, 9 Apr 2025 12:57:47 GMT, Raffaello Giulietti  wrote:

> Early detection of an `int` overflow in `StringConcatHelper` improves robustness of `StringConcatFactory`.

We can bump the copyright year.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24546#issuecomment-2789723891

From liach at openjdk.org  Wed Apr  9 13:31:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 13:31:27 GMT
Subject: RFR: 8354111: JavaDoc states that Iterator.remove() is linear in
 the LinkedBlockingDeque
In-Reply-To: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
References: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
Message-ID: 

On Tue, 8 Apr 2025 08:50:37 GMT, kabutz  wrote:

> One of the features of the LinkedBlockingDeque is that it is a doubly-linked node queue, with pointers in each node to "prev" and "next", which allows remove() in the Iterator to remove the node in constant time. However, in the JavaDoc of the class, it lists Iterator.remove() as an example of a method that takes linear time.

Thanks for going through this process; since there is no actual impact on all of source/target/behavioral compatibility you can uncheck all those. I have reviewed the CSR; you can finalize it now.

After CSRs are finalized, the CSR lead (currently Joe Darcy) checks periodically and review the CSRs. It may take a few days.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24500#issuecomment-2789736203

From rgiulietti at openjdk.org  Wed Apr  9 13:32:00 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 9 Apr 2025 13:32:00 GMT
Subject: RFR: 8351462: Improve robustness of String concatenation
In-Reply-To: <0M-TVwJNfVFGM37oYEQHrntixxa3YK-mIi2dLLOpURI=.f4d7fe87-5d41-4440-beb4-deb997a0e871@github.com>
References: <0M-TVwJNfVFGM37oYEQHrntixxa3YK-mIi2dLLOpURI=.f4d7fe87-5d41-4440-beb4-deb997a0e871@github.com>
Message-ID: 

On Wed, 9 Apr 2025 12:57:47 GMT, Raffaello Giulietti  wrote:

> Early detection of an `int` overflow in `StringConcatHelper` improves robustness of `StringConcatFactory`.

Oops...
Done

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24546#issuecomment-2789740924

From rgiulietti at openjdk.org  Wed Apr  9 13:32:00 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 9 Apr 2025 13:32:00 GMT
Subject: RFR: 8351462: Improve robustness of String concatenation [v2]
In-Reply-To: <0M-TVwJNfVFGM37oYEQHrntixxa3YK-mIi2dLLOpURI=.f4d7fe87-5d41-4440-beb4-deb997a0e871@github.com>
References: <0M-TVwJNfVFGM37oYEQHrntixxa3YK-mIi2dLLOpURI=.f4d7fe87-5d41-4440-beb4-deb997a0e871@github.com>
Message-ID: 

> Early detection of an `int` overflow in `StringConcatHelper` improves robustness of `StringConcatFactory`.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Bumped copyright year.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24546/files
  - new: https://git.openjdk.org/jdk/pull/24546/files/b491a1d8..ed313ded

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24546&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24546&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24546.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24546/head:pull/24546

PR: https://git.openjdk.org/jdk/pull/24546

From liach at openjdk.org  Wed Apr  9 13:37:31 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 13:37:31 GMT
Subject: RFR: 8354121: Use an anonymous class rather than a lambda in
 AbstractMemorySegmentImpl::cleanupAction [v3]
In-Reply-To: <6CmGQQA7cryhgsy3GSW2QkmqjAWugJR6VHhcXcphXEo=.2599bdac-9f84-4b28-a582-5acb387e3180@github.com>
References: 
 <6CmGQQA7cryhgsy3GSW2QkmqjAWugJR6VHhcXcphXEo=.2599bdac-9f84-4b28-a582-5acb387e3180@github.com>
Message-ID: 

On Wed, 9 Apr 2025 13:02:08 GMT, Per Minborg  wrote:

>> This PR proposes to use an anonymous class rather than a lambda in order to improve startup time.
>> 
>> We need to make sure the regression is fixed by this. It might be the case that the regression is there because [JDK-8347047](https://bugs.openjdk.org/browse/JDK-8347047) actually fixed an issue so that the segments could be collected by the GC.
>
> Per Minborg 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:
> 
>  - Use a record instead of anno class
>  - Merge branch 'master' into ms-reinterpret-remove-lambda
>  - Add comment on anonymous class
>  - Replace lambda with anonymous class

Thanks for this error-proof improvement. Remember to update the JBS issue and PR titles.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24514#pullrequestreview-2753513351

From liach at openjdk.org  Wed Apr  9 13:38:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 13:38:37 GMT
Subject: RFR: 8351462: Improve robustness of String concatenation [v2]
In-Reply-To: 
References: <0M-TVwJNfVFGM37oYEQHrntixxa3YK-mIi2dLLOpURI=.f4d7fe87-5d41-4440-beb4-deb997a0e871@github.com>
 
Message-ID: 

On Wed, 9 Apr 2025 13:32:00 GMT, Raffaello Giulietti  wrote:

>> Early detection of an `int` overflow in `StringConcatHelper` improves robustness of `StringConcatFactory`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bumped copyright year.

Looks good, thanks.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24546#pullrequestreview-2753509319

From pminborg at openjdk.org  Wed Apr  9 13:38:37 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 9 Apr 2025 13:38:37 GMT
Subject: RFR: 8351462: Improve robustness of String concatenation [v2]
In-Reply-To: 
References: <0M-TVwJNfVFGM37oYEQHrntixxa3YK-mIi2dLLOpURI=.f4d7fe87-5d41-4440-beb4-deb997a0e871@github.com>
 
Message-ID: 

On Wed, 9 Apr 2025 13:32:00 GMT, Raffaello Giulietti  wrote:

>> Early detection of an `int` overflow in `StringConcatHelper` improves robustness of `StringConcatFactory`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bumped copyright year.

LGTM. Thanks for the improvement!

-------------

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24546#pullrequestreview-2753515832

From pminborg at openjdk.org  Wed Apr  9 13:50:43 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 9 Apr 2025 13:50:43 GMT
Subject: Integrated: 8354121: Use a record class rather than a lambda in
 AbstractMemorySegmentImpl::cleanupAction
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 14:47:04 GMT, Per Minborg  wrote:

> This PR proposes to use an anonymous class rather than a lambda in order to improve startup time.
> 
> We need to make sure the regression is fixed by this. It might be the case that the regression is there because [JDK-8347047](https://bugs.openjdk.org/browse/JDK-8347047) actually fixed an issue so that the segments could be collected by the GC.

This pull request has now been integrated.

Changeset: c3e04395
Author:    Per Minborg 
URL:       https://git.openjdk.org/jdk/commit/c3e043956e72996a56a7ae9822782ba4dfdc0607
Stats:     13 lines in 1 file changed: 10 ins; 0 del; 3 mod

8354121: Use a record class rather than a lambda in AbstractMemorySegmentImpl::cleanupAction

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/24514

From duke at openjdk.org  Wed Apr  9 14:22:38 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 9 Apr 2025 14:22:38 GMT
Subject: RFR: 8353683: [REDO] j.u.l.Handler classes create deadlock risk
 via synchronized publish() method
In-Reply-To: <1hi7sIiW2Watca8P_a-LmCWFPEmXd3tFxoumdgfqWfA=.ecc0ba28-be14-48f2-bd5d-d238cb0ec070@github.com>
References: <2l5AHWU2u5_pJSlTHuCbW4NXM6Rzdq1vjvvoca0wKC0=.0a9cfc62-70dc-498e-816e-469ffbbca9ce@github.com>
 <1hi7sIiW2Watca8P_a-LmCWFPEmXd3tFxoumdgfqWfA=.ecc0ba28-be14-48f2-bd5d-d238cb0ec070@github.com>
Message-ID: 

On Tue, 8 Apr 2025 16:15:13 GMT, Chen Liang  wrote:

>> 8353683: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
>> 
>> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
>> 2. Add explanatory comments to various affected methods.
>> 3. Add a test to ensure deadlocks no longer occur.
>> 
>> Note that this change does not address issue in MemoryHandler (see JDK-8349208).
>
> src/java.logging/share/classes/java/util/logging/Handler.java line 46:
> 
>> 44:  * {@code Handler} class.
>> 45:  *
>> 46:  * 
Thread Safety and Deadlock Risk in Handlers

> 
> FYI you can add the id attribute to the h2 tag without declaring a separate a tag.

I'm copying exactly what Joe suggested, so I'll leave it like this for consistency. But thanks for pointing that out.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24504#discussion_r2035486048

From duke at openjdk.org  Wed Apr  9 14:30:44 2025
From: duke at openjdk.org (duke)
Date: Wed, 9 Apr 2025 14:30:44 GMT
Subject: RFR: 8353840: JNativeScan should not throw error for missing
 system classes [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 8 Apr 2025 13:51:59 GMT, Danish Nawab  wrote:

>> ## Description
>> 
>> https://bugs.openjdk.org/browse/JDK-8353840 
>> 
>> ### Existing behavior
>> Log the error message and terminate in case of missing system class
>> 
>> 
>> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?"
>> 
>> ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String
>> CAUSED BY: System class can not be found: sun.misc.JavaLangAccess
>> Exit code: 1
>> 
>> 
>> ### New behavior
>> Still log the error message about the missing system class, but continue the analysis
>> 
>> 
>> $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" 
>> 
>>   
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets
>> Exit code: 0
>> 
>> 
>> ## Design choices
>> 
>> Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis
>> 
>> ### Alternatives considered
>> 
>> - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`.
>>     - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception 
>> - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver`
>>     - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful
>> 
>> ### stdout vs stderr 
>> 
>> One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed....
>
> Danish Nawab has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8353840: remove unnecessary final

@danishnawab 
Your change (at version 1de3feca0a42ec1dfe4d8797fc362612277152a0) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24499#issuecomment-2789930714

From tschatzl at openjdk.org  Wed Apr  9 14:38:46 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 9 Apr 2025 14:38:46 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 8 Apr 2025 19:59:09 GMT, Albert Mingkun Yang  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 39 commits:
>> 
>>  - * missing file from merge
>>  - 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 submit/8342382-card-table-instead-of-dcq
>>  - * make young gen length revising independent of refinement thread
>>      * use a service task
>>      * both refinement control thread and young gen length revising use the same infrastructure to get the number of available bytes and determine the time to the next update
>>  - * fix IR code generation tests that change due to barrier cost changes
>>  - * factor out card table and refinement table merging into a single
>>      method
>>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq3
>>  - * obsolete G1UpdateBufferSize
>>    
>>    G1UpdateBufferSize has previously been used to size the refinement
>>    buffers and impose a minimum limit on the number of cards per thread
>>    that need to be pending before refinement starts.
>>    
>>    The former function is now obsolete with the removal of the dirty
>>    card queues, the latter functionality has been taken over by the new
>>    diagnostic option `G1PerThreadPendingCardThreshold`.
>>    
>>    I prefer to make this a diagnostic option is better than a product option
>>    because it is something that is only necessary for some test cases to
>>    produce some otherwise unwanted behavior (continuous refinement).
>>    
>>    CSR is pending.
>>  - ... and 29 more: https://git.openjdk.org/jdk/compare/41d4a0d7...1c5a669f
>
> src/hotspot/share/gc/g1/g1ConcurrentRefineSweepTask.cpp line 83:
> 
>> 81:         break;
>> 82:       }
>> 83:       case G1RemSet::HasRefToOld : break; // Nothing special to do.
> 
> Why doesn't call `inc_cards_clean_again` in this case? The card is cleared also. (In fact, I don't get why this needs to a separate case from `NoInteresting`.)

"NoInteresting" means that the card contains no interesting reference at all. "HasRefToOld" means that there has been an interesting reference in the card.

The distinction between these groups of cards seems interesting to me. E.g. out of X non-clean cards, there were A with a reference to the collection set, B that were already marked as containing a card to the collection, C not having any interesting card any more (transitioned from clean -> dirty -> clean, and cleared by the mutator), D being non-parsable, and E having references to old (and no other references).

I could add a separate counter for these type of cards too - they can be inferred from the total number of scanned minus the others though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035512686

From liach at openjdk.org  Wed Apr  9 14:46:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 14:46:46 GMT
Subject: RFR: 8353683: [REDO] j.u.l.Handler classes create deadlock risk
 via synchronized publish() method
In-Reply-To: <2l5AHWU2u5_pJSlTHuCbW4NXM6Rzdq1vjvvoca0wKC0=.0a9cfc62-70dc-498e-816e-469ffbbca9ce@github.com>
References: <2l5AHWU2u5_pJSlTHuCbW4NXM6Rzdq1vjvvoca0wKC0=.0a9cfc62-70dc-498e-816e-469ffbbca9ce@github.com>
Message-ID: 

On Tue, 8 Apr 2025 11:00:27 GMT, David Beaumont  wrote:

> 8353683: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

@stuart-marks Can you check this out?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24504#issuecomment-2789985709

From liach at openjdk.org  Wed Apr  9 15:04:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 15:04:24 GMT
Subject: RFR: 8352748: Remove com.sun.tools.classfile from the JDK [v2]
In-Reply-To: 
References: 
Message-ID: 

> With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.
> 
> Testing: built locally, running tier 1-3 tests
> 
> Don't know why, but GitHub is redundantly displaying changes that are already in #24212.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
 - 8352748: Remove com.sun.tools.classfile from the JDK
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
 - Other references to remove
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
 - FieldDescription.constantValue uses Integer for byte and short
 - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

-------------

Changes: https://git.openjdk.org/jdk/pull/24528/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24528&range=01
  Stats: 10015 lines in 70 files changed: 0 ins; 10009 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24528/head:pull/24528

PR: https://git.openjdk.org/jdk/pull/24528

From rriggs at openjdk.org  Wed Apr  9 15:04:44 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 9 Apr 2025 15:04:44 GMT
Subject: RFR: 8351462: Improve robustness of String concatenation [v2]
In-Reply-To: 
References: <0M-TVwJNfVFGM37oYEQHrntixxa3YK-mIi2dLLOpURI=.f4d7fe87-5d41-4440-beb4-deb997a0e871@github.com>
 
Message-ID: 

On Wed, 9 Apr 2025 13:32:00 GMT, Raffaello Giulietti  wrote:

>> Early detection of an `int` overflow in `StringConcatHelper` improves robustness of `StringConcatFactory`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bumped copyright year.

Looks good

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24546#pullrequestreview-2753819343

From ihse at openjdk.org  Wed Apr  9 15:09:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 15:09:58 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: 
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 
Message-ID: <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>

On Thu, 11 May 2023 20:21:57 GMT, Justin Lu  wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Convert the merged master changes to UTF-8
>  - Merge master and fix conflicts
>  - Close streams when finished loading into props
>  - Adjust CF test to read in with UTF-8 to fix failing test
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties line 22:

> 20: # Peter Smolik
> 21: Cp1250 WINDOWS-1250 0x00FF
> 22: # Patch attributed to havardw at underdusken.no (H?vard Wigtil)

This does not seem to have been a correct conversion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2035582242

From liach at openjdk.org  Wed Apr  9 15:14:29 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 15:14:29 GMT
Subject: RFR: 8353840: JNativeScan should not abort for missing classes
 [v3]
In-Reply-To: 
References: 
 
Message-ID: <5Ei6jXfX8xHlWEealxWf8Tlqaq47-yZ5Wv_Ofpg5G9U=.f0fa3a2f-1288-4382-a510-c6f8d5609260@github.com>

On Tue, 8 Apr 2025 13:51:59 GMT, Danish Nawab  wrote:

>> ## Description
>> 
>> https://bugs.openjdk.org/browse/JDK-8353840 
>> 
>> ### Existing behavior
>> Log the error message and terminate in case of missing system class
>> 
>> 
>> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?"
>> 
>> ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String
>> CAUSED BY: System class can not be found: sun.misc.JavaLangAccess
>> Exit code: 1
>> 
>> 
>> ### New behavior
>> Still log the error message about the missing system class, but continue the analysis
>> 
>> 
>> $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" 
>> 
>>   
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets
>> Exit code: 0
>> 
>> 
>> ## Design choices
>> 
>> Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis
>> 
>> ### Alternatives considered
>> 
>> - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`.
>>     - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception 
>> - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver`
>>     - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful
>> 
>> ### stdout vs stderr 
>> 
>> One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed....
>
> Danish Nawab has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8353840: remove unnecessary final

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24499#pullrequestreview-2753847531

From liach at openjdk.org  Wed Apr  9 15:14:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 15:14:30 GMT
Subject: RFR: 8353840: JNativeScan should not abort for missing classes
 [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: <00fbDY9dGX80hw-oX9eTKIV5vTn3cZy4s8iUAjZz6_I=.badcf9e9-154c-4c07-a827-cd396c4a76ea@github.com>

On Tue, 8 Apr 2025 14:25:11 GMT, Danish Nawab  wrote:

>> Changes look good, thanks!
>> 
>> Please note that we will have to wait 24 hours before integrating, in order to give other reviews time to look as well.
>
>> Changes look good, thanks!
>> 
>> Please note that we will have to wait 24 hours before integrating, in order to give other reviews time to look as well.
> 
> Great, thanks for your review! 
> I will wait until tomorrow to issue the `/integrate` (as instructed by openjdk[bot]). Since I am not an OpenJDK committer, I will request you to please sponsor it.

Hello @danishnawab, I have updated the issue title to "JNativeScan should not abort for missing classes" to be more accurate for the changes done. Can you update the PR title here too?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24499#issuecomment-2790067812

From duke at openjdk.org  Wed Apr  9 15:17:26 2025
From: duke at openjdk.org (Danish Nawab)
Date: Wed, 9 Apr 2025 15:17:26 GMT
Subject: RFR: 8353840: JNativeScan should not abort for missing classes
 [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 8 Apr 2025 14:25:11 GMT, Danish Nawab  wrote:

>> Changes look good, thanks!
>> 
>> Please note that we will have to wait 24 hours before integrating, in order to give other reviews time to look as well.
>
>> Changes look good, thanks!
>> 
>> Please note that we will have to wait 24 hours before integrating, in order to give other reviews time to look as well.
> 
> Great, thanks for your review! 
> I will wait until tomorrow to issue the `/integrate` (as instructed by openjdk[bot]). Since I am not an OpenJDK committer, I will request you to please sponsor it.

> Hello @danishnawab, I have updated the issue title to "JNativeScan should not abort for missing classes" to be more accurate for the changes done. Can you update the PR title here too?

@liach it's done.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24499#issuecomment-2790078272

From jlahoda at openjdk.org  Wed Apr  9 15:17:33 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 9 Apr 2025 15:17:33 GMT
Subject: RFR: 8352748: Remove com.sun.tools.classfile from the JDK [v2]
In-Reply-To: 
References: 
 
Message-ID: <8fGvLxgB44Zln3uK7Htt3LWMvCkiTYqpsGKNTDDJ7Do=.19e52043-d624-44b3-a901-85869fe9498c@github.com>

On Wed, 9 Apr 2025 15:04:24 GMT, Chen Liang  wrote:

>> With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.
>> 
>> Testing: built locally, running tier 1-3 tests
>> 
>> Don't know why, but GitHub is redundantly displaying changes that are already in #24212.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
>  - 8352748: Remove com.sun.tools.classfile from the JDK
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - Other references to remove
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - FieldDescription.constantValue uses Integer for byte and short
>  - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

Looks good to me. I won't increase the reviewer count, but please wait a few days to give others chance to comment if they choose to.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24528#pullrequestreview-2753858690

From pminborg at openjdk.org  Wed Apr  9 15:17:34 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 9 Apr 2025 15:17:34 GMT
Subject: RFR: 8350075: Performance difference between SegmentAllocator
 methods
In-Reply-To: 
References: 
Message-ID: <1IQOKSpavlKjtj3m3FAVdYY4XjC7fHRf_b40nAFyhsI=.12c8f382-590d-47a7-8500-31943e59aa56@github.com>

On Fri, 14 Feb 2025 09:19:35 GMT, Per Minborg  wrote:

> This PR proposes to add `@ForceInline` to the `default` methods in `SegmentAllocator` that do not already have it.

Keep it open.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23628#issuecomment-2790078845

From rgiulietti at openjdk.org  Wed Apr  9 15:18:37 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 9 Apr 2025 15:18:37 GMT
Subject: Integrated: 8351462: Improve robustness of String concatenation
In-Reply-To: <0M-TVwJNfVFGM37oYEQHrntixxa3YK-mIi2dLLOpURI=.f4d7fe87-5d41-4440-beb4-deb997a0e871@github.com>
References: <0M-TVwJNfVFGM37oYEQHrntixxa3YK-mIi2dLLOpURI=.f4d7fe87-5d41-4440-beb4-deb997a0e871@github.com>
Message-ID: 

On Wed, 9 Apr 2025 12:57:47 GMT, Raffaello Giulietti  wrote:

> Early detection of an `int` overflow in `StringConcatHelper` improves robustness of `StringConcatFactory`.

This pull request has now been integrated.

Changeset: 1f21da75
Author:    Raffaello Giulietti 
URL:       https://git.openjdk.org/jdk/commit/1f21da75eb5d5eb7460b2953517514a0aa26b5de
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8351462: Improve robustness of String concatenation

Reviewed-by: liach, pminborg, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/24546

From liach at openjdk.org  Wed Apr  9 15:28:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 15:28:37 GMT
Subject: RFR: 8353840: JNativeScan should not abort for missing classes
 [v3]
In-Reply-To: 
References: 
 
Message-ID: <60i3YYy1zyJAWbMQ9ddazxVQn92FazdkDBqlQuT66Uk=.eaa161d8-e21d-4998-962c-dab86d0f311e@github.com>

On Tue, 8 Apr 2025 13:51:59 GMT, Danish Nawab  wrote:

>> ## Description
>> 
>> https://bugs.openjdk.org/browse/JDK-8353840 
>> 
>> ### Existing behavior
>> Log the error message and terminate in case of missing system class
>> 
>> 
>> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?"
>> 
>> ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String
>> CAUSED BY: System class can not be found: sun.misc.JavaLangAccess
>> Exit code: 1
>> 
>> 
>> ### New behavior
>> Still log the error message about the missing system class, but continue the analysis
>> 
>> 
>> $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" 
>> 
>>   
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets
>> Exit code: 0
>> 
>> 
>> ## Design choices
>> 
>> Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis
>> 
>> ### Alternatives considered
>> 
>> - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`.
>>     - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception 
>> - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver`
>>     - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful
>> 
>> ### stdout vs stderr 
>> 
>> One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed....
>
> Danish Nawab has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8353840: remove unnecessary final

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24499#issuecomment-2790105523

From duke at openjdk.org  Wed Apr  9 15:28:38 2025
From: duke at openjdk.org (Danish Nawab)
Date: Wed, 9 Apr 2025 15:28:38 GMT
Subject: Integrated: 8353840: JNativeScan should not abort for missing classes
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 08:18:36 GMT, Danish Nawab  wrote:

> ## Description
> 
> https://bugs.openjdk.org/browse/JDK-8353840 
> 
> ### Existing behavior
> Log the error message and terminate in case of missing system class
> 
> 
> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?"
> 
> ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String
> CAUSED BY: System class can not be found: sun.misc.JavaLangAccess
> Exit code: 1
> 
> 
> ### New behavior
> Still log the error message about the missing system class, but continue the analysis
> 
> 
> $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" 
> 
>   
> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess
> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets
> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets
> Exit code: 0
> 
> 
> ## Design choices
> 
> Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis
> 
> ### Alternatives considered
> 
> - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`.
>     - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception 
> - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver`
>     - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful
> 
> ### stdout vs stderr 
> 
> One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed.
> 
> ## Testing
> 
> The existing test `TestMissingSystemClass#testSingleJarClassPath` has ...

This pull request has now been integrated.

Changeset: 5f2a604b
Author:    Danish Nawab 
Committer: Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/5f2a604b633c0cd24f897f828a7c928c3d2b651c
Stats:     54 lines in 5 files changed: 25 ins; 2 del; 27 mod

8353840: JNativeScan should not abort for missing classes

Reviewed-by: jvernee, liach

-------------

PR: https://git.openjdk.org/jdk/pull/24499

From liach at openjdk.org  Wed Apr  9 15:34:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 15:34:25 GMT
Subject: RFR: 8333377: Migrate Generic Signature parsing to ClassFile API
 [v6]
In-Reply-To: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com>
References: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com>
Message-ID: 

> Core reflection's generic signature parsing uses an ancient library with outdated visitor pattern on a tree model and contains unnecessary boilerplates. This is a duplication of ClassFile API's signature model. We should just move to ClassFile API, which is more throughoutly tested as well.
> 
> To ensure compatibility, new tests are added to ensure consistent behavior when encountering malformed signatures or signatures with missing types. The reflective objects have been preserved and the only change is that lazy expansion now happens from CF objects, to reduce compatibility risks.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info
 - Improve BytecodeDescriptor error message
 - Years, test facelift
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info
 - 8333377: Migrate Generic Signature parsing to ClassFile API

-------------

Changes: https://git.openjdk.org/jdk/pull/19281/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19281&range=05
  Stats: 4190 lines in 62 files changed: 567 ins; 3517 del; 106 mod
  Patch: https://git.openjdk.org/jdk/pull/19281.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19281/head:pull/19281

PR: https://git.openjdk.org/jdk/pull/19281

From vromero at openjdk.org  Wed Apr  9 15:43:42 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 9 Apr 2025 15:43:42 GMT
Subject: RFR: 8352748: Remove com.sun.tools.classfile from the JDK [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 9 Apr 2025 15:04:24 GMT, Chen Liang  wrote:

>> With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.
>> 
>> Testing: built locally, running tier 1-3 tests
>> 
>> Don't know why, but GitHub is redundantly displaying changes that are already in #24212.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
>  - 8352748: Remove com.sun.tools.classfile from the JDK
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - Other references to remove
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - FieldDescription.constantValue uses Integer for byte and short
>  - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

lgtm

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24528#pullrequestreview-2753941212

From jvernee at openjdk.org  Wed Apr  9 16:00:52 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 9 Apr 2025 16:00:52 GMT
Subject: RFR: 8353917: jnativescan: Simplify ClassResolver [v2]
In-Reply-To: 
References: 
Message-ID: 

> `jnativescan` uses the `ClassResolver` class to find both system classes, as well as application classes. In principle, a class resolver supports both iterating over all classes from that particular source, as well as looking up classes by name. However, the `ClassResolver` for system classes doesn't support iterating, and the lookup functionality for `ClassResolvers` from other sources is never used (only iterating).
> 
> This patch proposes to split the iterating functionality out of `ClassResolver`. Clients that were using this functionality will switch to using the iteration functionality that is available on `ClassFileSource` directly (whose classes were previously being wrapped in a `ClassResolver`). As a result of this latter change, we can now also let `NativeMethodFinder` operate on individual classes. We just iterate over all the class file sources in `JNativeScanTask`, and feed individual class models to `NativeMethodFinder`. I think this is a good conceptual simplification of `NativeMethodFinder`,
> 
> Since `ClassResolver` is now only used for system classes, I've removed it, leaving only its single implementation: `SystemClassResolver`.
> 
> Testing: running `langtools_jnativescan` test suite.

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into jnativescan_Refactor
 - bump copyright years
 - merge ClassResolver and SystemClassResolver
 - Simplify ClassResolver

-------------

Changes: https://git.openjdk.org/jdk/pull/24493/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24493&range=01
  Stats: 371 lines in 5 files changed: 147 ins; 191 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/24493.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24493/head:pull/24493

PR: https://git.openjdk.org/jdk/pull/24493

From sgehwolf at openjdk.org  Wed Apr  9 16:10:20 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 9 Apr 2025 16:10:20 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v5]
In-Reply-To: 
References: 
Message-ID: 

> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
> 
> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
> 
> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
> 2. For those files the hash sum checks are skipped.
> 
> **Testing**
> 
> - [x] GHA
> - [x] `jdk/tools/jlink` jtreg tests (also on [GHA](https://github.com/jerboaa/jdk/actions/runs/14308729271))
> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
> 
> Thoughts?

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Use *.conf for upgrade files

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24388/files
  - new: https://git.openjdk.org/jdk/pull/24388/files/89d3886d..4434c78e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24388&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24388&range=03-04

  Stats: 11 lines in 4 files changed: 6 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24388/head:pull/24388

PR: https://git.openjdk.org/jdk/pull/24388

From jengebr at amazon.com  Wed Apr  9 16:35:32 2025
From: jengebr at amazon.com (Engebretson, John)
Date: Wed, 9 Apr 2025 16:35:32 +0000
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: 
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 
 <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 
 
 <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
 
Message-ID: <3f1c69a7ac5946809d2af850d7d59db9@amazon.com>

I think there is agreement that ByteArrayOutputStream.unsynchronized(int cap) (or some such method) would be useful. It would not require using a contiguous byte[] as the backing array so there is scope to experiment with implementations that don't need to resize like the base BAOS does.

Extending BOAS means the size is limited to an int. To go beyond would be a different API and there is lots of scope to do experiments. I think too early to create a CSR for MOS, assuming this is what you mean.

  Thank you Alan!  PR [1] is updated with the factory method as suggested; MOS is a package-private subclass of BAOS and the Javadoc in BAOS makes no promises about the implementation returned.  I allowed MOS to grow beyond 2GB and throw an intelligent error if it cannot service a particular call (toByteArray, size, etc.).  Performance is unchanged.  Feedback appreciated.
  Thanks!  ?
     John

[1] https://github.com/openjdk/jdk/pull/24232

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From tpushkin at openjdk.org  Wed Apr  9 16:46:36 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 9 Apr 2025 16:46:36 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v5]
In-Reply-To: 
References: 
 <9nX8O13jWi7qORu4uO-ppDmlph2W2lH1VVIKFP3-Gt8=.46545db1-b218-497d-b4ef-546410b09b9b@github.com>
 
 
Message-ID: 

On Wed, 9 Apr 2025 09:03:41 GMT, Timofei Pushkin  wrote:

>> src/java.base/share/classes/jdk/internal/misc/CDS.java line 438:
>> 
>>> 436:             // class loader. Thus it is safe to delegate their loading to system class loader
>>> 437:             // (our parent) - this is what the default implementation of loadClass() will do.
>>> 438:             return defineClass(name, bytes, 0, bytes.length);
>> 
>> I didn't realize that `URLClassLoader` will by default delegate to `ClassLoader::getSystemClassLoader()`. How about rewording the comments like this to clarify?
>> 
>> 
>> // defineClass() will internally invoke loadClass() to load supertypes of this unregistered class.
>> // Any supertype S with the name SN must have already been loaded (enforced by the order
>> // of classes in the classlist). In addition:
>> // - if S is an unregistered class, S must have already been have been defined by the current class
>> //   loader, and will be found by `this.findLoadedClass(SN)`
>> // - if S is not an unregistered class, S must have already been defined by the built-in boot,
>> //   platform, or system class loaders, and can be found by this.getParent().loadClass(SN, false)
>> // See the implementation of ClassLoader::loadClass() for details.
>> //
>> // Therefore, we should resolve all supertypes to the expected ones as specified by the
>> // super: and interfaces: attributes in the classlist. This
>> // invariance is validated by the C++ function ClassListParser::load_class_from_source()
>> assert getParent() == getSystemClassLoader();
>> return defineClass(name, bytes, 0, bytes.length);
>
> I've actually noticed a problem here. I assumed that registered classes are always loaded by JDK's built-in class loaders (bootstrap, `jdk.internal.loader.ClassLoaders$PlatformClassLoader` or `jdk.internal.loader.ClassLoaders$AppClassLoader`). But in reality when the system class loader is user-provided (via `-Djava.system.class.loader=`) classes loaded by it are still considered registered. This is a problem because such user-provided class loader may not delegate to real built-in class loaders.
> 
> For example:
> - Let C= be a class C named N defined by class loader L
> - Let AppL be the built-in system class loader and SysL be the user-provided system class loader
> - Let U be an unregistered class which extends a registered 
> - Let SysL be able to load a registered  when requested (i.e. SysL doesn't delegate when loading a class named S)
> - When `UnregisteredClassLoader` will be loading U it will delegate the loading of its super named S to SysL and thus  will become a super of U instead of  ? this is not correct
> 
> This won't be a problem if only classes loaded by the real built-in class loaders would be considered registered because such class loaders always delegate first (the 4th bullet above won't be possible), and thus it doesn't matter which of these loaders was used for delegation by the class loader which defined U.
> 
> This can't be fixed by just making `jdk.internal.loader.ClassLoaders$AppClassLoader` a parent of `UnregisteredClassLoader` and making `UnregisteredClassLoader.findClass(name)` return `getSystemClassLoader().loadClass(name)` because then the case when U extends  will not be handeled correctly ( will be used instead of ).
> 
> So it looks like I have to revert this delegation-based approach and use the old way. I'll also write a test from the above example to see if I am correct first.

I've realized that my example above cannot be expressed in the current class list format since the format doesn't distinguish between  and , only that S is not unregistered. The existing implementation (without this PR) will always use . It feels like a flaw to me but it is not a flaw of this patch.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2035755124

From smarks at openjdk.org  Wed Apr  9 16:57:40 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 9 Apr 2025 16:57:40 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 9 Apr 2025 10:46:40 GMT, Alan Bateman  wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rewrite bits about charset decoding, removing mention of "internal objects."
>
> src/java.base/share/classes/java/lang/IO.java line 42:
> 
>> 40:  * {@code System.in} into characters. The charset used for decoding is specified by the
>> 41:  * {@link System#getProperties stdin.encoding} property. If this property is not present,
>> 42:  * or if the charset it names cannot be loaded, then UTF-8 is used instead.
> 
> stdout.encoding and stderr.encoding are specified (in System.getProperties) to lead to unspecified behavior if started with either property set to a value other than UTF-8. We should work through the issues of introducing stdin.encoding as soon as we can, esp. the redirect cases and whether there is use cases for setting any of these properties on the command line.

Yes, believe it or not, I am still studying this...

> src/java.base/share/classes/java/lang/IO.java line 47:
> 
>> 45:  * Decoding may buffer additional bytes beyond those that have been decoded to characters
>> 46:  * returned to the application. After the first call to one of the {@code readln} methods,
>> 47:  * any subsequent use of {@code System.in} results in unspecified behavior.
> 
> I wonder if we should add a note about mixing API usage into System.in too. There are tutorials and books that show examples build on System.in that will add buffering on that input source.

Might be a good idea. I'll handle this separately. I don't want it to refer to a Preview API. I'll probably just use Scanner and InputStreamReader as examples.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2035772247
PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2035773250

From smarks at openjdk.org  Wed Apr  9 17:05:38 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 9 Apr 2025 17:05:38 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v3]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Wed, 9 Apr 2025 10:36:53 GMT, Alan Bateman  wrote:

>> The IOError was carried over from Console.readLine(), which throws IOError on error. Of course we're decoupled from Console now, but that was the original reason.
>> 
>> My guess is that Console methods throw IOError because (a) they didn't want to make everybody catch IOException, (b) they didn't want to maintain an internal error state like PrintStream, and (c) they wanted to throw a throwable whose type conveyed the meaning that it wasn't expected to be handled. IOError and Console were both added in JDK 1.6. Maybe that reasoning still applies here.
>> 
>> UncheckedIOException wasn't added until JDK 1.8. Note also that UncheckedIOException has a cause of IOException, so it can't arise from some other throwable. This was used in the previous implementation, where IOError was thrown if Console was null. That doesn't apply anymore, but IOError is still somewhat more flexible than UncheckedIOException in this regard.
>> 
>> I think we need to say something, implicitly or explicitly, about error handling. Note that PrintStream has this internal error state so output is covered already. For input it seems like IOError is reasonable, but maybe there's a better choice.
>
> The readln methods handle malformed-input and unmappable-character errors by dropping, and using a replacement value. So erroneous input doesn't throw IOError with a CharacterCodingException as the cause.
> 
> System.in.close() would a be wild thing to do, but a case where readln would throw IOError.

Ah. Does the specification here need to state the policy around malformed input and unmappable characters? (Or, maybe in the class specification.)

People have ended up in cases where System.in is closed. It can occur when combining use of Scanner to read from System.in and applying the anything-that-you-open-must-be-closed rule, e.g.,

    try (Scanner sc = new Scanner(System.in)) {
        String s = sc.nextLine();
    }

which is a mistake, but it takes a long time to explain....

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2035784546

From forax at openjdk.org  Wed Apr  9 17:19:49 2025
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 9 Apr 2025 17:19:49 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v51]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 7 Apr 2025 16:00:41 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in return type

src/java.base/share/classes/java/lang/StableValue.java line 397:

> 395:  * collections are built on top of StableValue. As such, they are also treated as
> 396:  * constants by the JFM.
> 397:  * 


JFM -> JVM

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2035804609

From forax at openjdk.org  Wed Apr  9 17:27:49 2025
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 9 Apr 2025 17:27:49 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v51]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 7 Apr 2025 16:00:41 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in return type

Hello,
I do not know if you know but StableValue.map() does not seems to be optimized correctly.

Here is the benchmark i use:

@Warmup(iterations = 5, time = 2, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 2, timeUnit = TimeUnit.SECONDS)
@Fork(value = 1, jvmArgs = { "--enable-preview" })
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Benchmark)
public class StableValueBenchmarks {
  private static final MemoryLayout LAYOUT = MemoryLayout.structLayout(
      ValueLayout.JAVA_INT.withName("x"),
      ValueLayout.JAVA_INT.withName("y")
  );

  private static final long SIZEOF = LAYOUT.byteSize();
  private static final long OFFSET_X = LAYOUT.byteOffset(groupElement("x"));
  private static final long OFFSET_Y = LAYOUT.byteOffset(groupElement("y"));

  private static final VarHandle VH_X = LAYOUT.arrayElementVarHandle(groupElement("x"))
      .withInvokeExactBehavior();
  private static final VarHandle VH_Y = LAYOUT.arrayElementVarHandle(groupElement("y"))
      .withInvokeExactBehavior();

  private static final Supplier SV_X = StableValue.supplier(
      () -> LAYOUT.arrayElementVarHandle(groupElement("x")).withInvokeExactBehavior());
  private static final Supplier SV_Y = StableValue.supplier(
      () -> LAYOUT.arrayElementVarHandle(groupElement("y")).withInvokeExactBehavior());

  private static final Map SMAP = StableValue.map(
      Set.of("x", "y"),
      name -> LAYOUT.arrayElementVarHandle(groupElement(name)).withInvokeExactBehavior());

  private final MemorySegment confined;
  {
    var array = new int[512 * (int) SIZEOF / (int) ValueLayout.JAVA_INT.byteSize()];
    var heap = MemorySegment.ofArray(array);
    for(var i = 0; i < 512; i++) {
      heap.set(ValueLayout.JAVA_INT, i * SIZEOF + OFFSET_X, i);
      heap.set(ValueLayout.JAVA_INT, i * SIZEOF + OFFSET_Y, i);
    }
    confined = Arena.ofConfined().allocate(LAYOUT, 512);
    confined.copyFrom(heap);
  }

  @Benchmark
  public int confinedVarHandleLoop() {
    var sum = 0;
    for(var i = 0; i < 512; i++) {
      var x = (int) VH_X.get(confined, 0L, (long) i);
      var y = (int) VH_Y.get(confined, 0L, (long) i);
      sum += x +y;
    }
    return sum;
  }

  @Benchmark
  public int confinedStableValueLoop() {
    var sum = 0;
    for(var i = 0; i < 512; i++) {
      var x = (int) SV_X.get().get(confined, 0L, (long) i);
      var y = (int) SV_Y.get().get(confined, 0L, (long) i);
      sum += x +y;
    }
    return sum;
  }

  @Benchmark
  public int confinedStableMapLoop() {
    var sum = 0;
    for(var i = 0; i < 512; i++) {
      var x = (int) SMAP.get("x").get(confined, 0L, (long) i);
      var y = (int) SMAP.get("y").get(confined, 0L, (long) i);
      sum += x +y;
    }
    return sum;
  }
}


Results for Stable.map() are way of:

Benchmark                                      Mode  Cnt      Score    Error  Units
StableValueBenchmarks.confinedStableMapLoop    avgt    5  21832,999 ? 50,422  ns/op
StableValueBenchmarks.confinedStableValueLoop  avgt    5    144,546 ?  0,640  ns/op
StableValueBenchmarks.confinedVarHandleLoop    avgt    5    146,320 ?  1,789  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2790451306

From alanb at openjdk.org  Wed Apr  9 17:55:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 17:55:47 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 2 Apr 2025 16:59:16 GMT, Jan Lahoda  wrote:

>> This is a patch to finalize the module imports feature. Please see:
>> https://bugs.openjdk.org/browse/JDK-8344700
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback - avoiding hardcoded constants.

src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 415:

> 413:                 if (major >= 54
> 414:                     && mods.contains(Requires.Modifier.STATIC)) {
> 415:                     String flagName = "ACC_STATIC_PHASE";

A minor comment on the style here, do you mind combin L413+414 as it will make it easier to read. The change is okay of course.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23801#discussion_r2035855402

From weijun at openjdk.org  Wed Apr  9 18:15:03 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 9 Apr 2025 18:15:03 GMT
Subject: RFR: 8353888: Implement Key Derivation Function API [v3]
In-Reply-To: 
References: 
Message-ID: 

> Finalize the KDF API.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  update @since tags as required by JEP 12

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24520/files
  - new: https://git.openjdk.org/jdk/pull/24520/files/66706a50..a55c5069

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=01-02

  Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24520.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24520/head:pull/24520

PR: https://git.openjdk.org/jdk/pull/24520

From tpushkin at openjdk.org  Wed Apr  9 18:37:15 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 9 Apr 2025 18:37:15 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v6]
In-Reply-To: 
References: 
Message-ID: 

> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app.
> 
> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible.

Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:

  Remove findClass, extend explanation comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24223/files
  - new: https://git.openjdk.org/jdk/pull/24223/files/dff524c4..903f0f97

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=04-05

  Stats: 25 lines in 1 file changed: 11 ins; 7 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24223.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223

PR: https://git.openjdk.org/jdk/pull/24223

From naoto at openjdk.org  Wed Apr  9 19:38:25 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 9 Apr 2025 19:38:25 GMT
Subject: RFR: 8351740: Clean up some code around initialization of encoding
 properties [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 7 Apr 2025 23:43:29 GMT, Stuart Marks  wrote:

>> Some of the code that creates various encoding properties at JVM initialization time, such as file.encoding and native.encoding, could use some cleaning up. Cleanup is fairly minimal and should be mostly behavior-preserving. Changes include the following:
>> 
>> * In the java_props.h and java_props_md.c files, add documentation and asserts that the sprops.encoding and sprops.sun_jnu_encoding members are always set to non-NULL by the platform-specific code.
>> 
>> * In SystemProps.java, remove a null check that is now extraneous based on the above assertion.
>> 
>> * In SystemProps.java, rearrange logic (with no behavior change) around handling of the "COMPAT" value for the file.encoding property.
>> 
>> * In SystemProps.Raw, rename the platform properties array index from _file_encoding_NDX to _native_encoding_NDX.
>> 
>> * In SystemProps.Raw.cmdProperties(), adjust the HashMap size computation. This should actually avoid resizing of the HashMap (unlike the earlier code).
>> 
>> * Adjust various comments in several places for clarity and correctness.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment from file.encoding to native.encoding

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24463#pullrequestreview-2754595724

From sgehwolf at openjdk.org  Wed Apr  9 19:53:36 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 9 Apr 2025 19:53:36 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v17]
In-Reply-To: 
References: 
 
Message-ID: <8J81yHp6pB8F9BtQfyXPziqyCCrQP5NSasjiu5HzGWg=.db593ac0-7259-4cda-832d-1e872114db44@github.com>

On Tue, 1 Apr 2025 14:59:37 GMT, Severin Gehwolf  wrote:

>> Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes.
>> 
>> For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of  `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`).
>> 
>> This patch addresses this issue by:
>> 
>> 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2.
>> 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value).
>> 
>> As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems.
>> 
>> This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been added in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests.
>> 
>> Thoughts?
>> 
>> Testing:
>> 
>> - [x] GHA
>> - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems
>> - [x] Some manual testing using systemd slices
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:
> 
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - JDK-8350103
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Fix missing imports
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - ... and 34 more: https://git.openjdk.org/jdk/compare/6801eb87...32960cd6

Keep open, please.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2790835637

From bchristi at openjdk.org  Wed Apr  9 19:54:55 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 9 Apr 2025 19:54:55 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v2]
In-Reply-To: 
References: 
Message-ID: 

> Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead to intermittent test failures ([JDK-8298783](https://bugs.openjdk.org/browse/JDK-8298783)  is a recent example).
> 
> A better mechanism already exists in the private `Reference.waitForReferenceProcessing()` method. This PR makes `waitForReferenceProcessing()` available to tests via the `WhiteBox` and `ForceGC` test libraries.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  only add wFRP to WhiteBox for now

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24527/files
  - new: https://git.openjdk.org/jdk/pull/24527/files/df4c4a92..f665678f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24527&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24527&range=00-01

  Stats: 30 lines in 1 file changed: 1 ins; 28 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24527/head:pull/24527

PR: https://git.openjdk.org/jdk/pull/24527

From bchristi at openjdk.org  Wed Apr  9 19:54:55 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 9 Apr 2025 19:54:55 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 8 Apr 2025 22:44:57 GMT, Kim Barrett  wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   only add wFRP to WhiteBox for now
>
> test/lib/jdk/test/lib/util/ForceGC.java line 117:
> 
>> 115:      * jtreg tag.
>> 116:      *
>> 117:      * This method should usually be called after a call to WhiteBox.fullGC().
> 
> I suggest waiting until we have a use-case for WFRP _without_ `WB.fullGC` before adding this.
> That's because I'm doubtful that such a use-case exists.

OK - can add it just to `WhiteBox` for now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2036048204

From bchristi at openjdk.org  Wed Apr  9 19:54:55 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 9 Apr 2025 19:54:55 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 8 Apr 2025 22:55:53 GMT, Brent Christian  wrote:

>> test/lib/jdk/test/whitebox/WhiteBox.java line 569:
>> 
>>> 567:    * This method should usually be called after a call to WhiteBox.fullGC().
>>> 568:    */
>>> 569:   public static void waitForReferenceProcessing() {
>> 
>> Can the code duplication be avoided?
>
> That would be nice.
> A primary goal here is to not disrupt existing tests that use `WhiteBox` or `ForceGC`, (e.g. by necessitating additional tags, `@run` arguments, etc).
> I don't think there's a way for `WhiteBox.java` and `ForceGC.java` to both refer to code at some shared location without tests having to add a new tag - `@build`, I think.
> However I will look into it a bit further.

(No code duplication if just adding to WhiteBox.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2036049957

From ihse at openjdk.org  Wed Apr  9 20:26:33 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 20:26:33 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 9 Apr 2025 16:10:20 GMT, Severin Gehwolf  wrote:

>> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
>> 
>> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
>> 
>> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
>> 2. For those files the hash sum checks are skipped.
>> 
>> **Testing**
>> 
>> - [x] GHA
>> - [x] `jdk/tools/jlink` jtreg tests (also on [GHA](https://github.com/jerboaa/jdk/actions/runs/14308729271))
>> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use *.conf for upgrade files

Build changes look good now. Thanks!

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24388#pullrequestreview-2754729383

From smarks at openjdk.org  Wed Apr  9 20:39:38 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 9 Apr 2025 20:39:38 GMT
Subject: RFR: 8353683: [REDO] j.u.l.Handler classes create deadlock risk
 via synchronized publish() method
In-Reply-To: <2l5AHWU2u5_pJSlTHuCbW4NXM6Rzdq1vjvvoca0wKC0=.0a9cfc62-70dc-498e-816e-469ffbbca9ce@github.com>
References: <2l5AHWU2u5_pJSlTHuCbW4NXM6Rzdq1vjvvoca0wKC0=.0a9cfc62-70dc-498e-816e-469ffbbca9ce@github.com>
Message-ID: <_DcQFgen2T4RoDJvj36mfUNUt1_o1eaxTwUxhaFVSDg=.a798d3b6-35ed-4264-94cf-e8f2c32043ec@github.com>

On Tue, 8 Apr 2025 11:00:27 GMT, David Beaumont  wrote:

> 8353683: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

Looks good. I'll suggest that @dfuch sponsor this time. :-D

-------------

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24504#pullrequestreview-2754755106

From asemenyuk at openjdk.org  Wed Apr  9 20:50:17 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 9 Apr 2025 20:50:17 GMT
Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables
 available in *.cfg files [v9]
In-Reply-To: 
References: 
Message-ID: 

> jpackage app laucnher will expand environment variables in .cfg files.
> 
> Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and `$ROOTDIR` tokens with the corresponding path values. With this patch, any environment variable can be expanded. The syntax is shell-like `$ENV_VAR_NAME` or `${ENV_VAR_NAME}`. If `$ENV_VAR_NAME` syntax is used, the variable name stops at the first character outside of `[a-zA-Z0-9_]` character range. If `${ENV_VAR_NAME}` syntax is used, the variable name stops at the first `}` character after `${` substring. E.g:
> | String    | Variables | Variable Values | Expanded String | Note |
> | -------- | ------- |------- |------- |------- |
> | 
Welcome $USER!
  | 
USER
 | 
USER=John
 | 
Welcome John!
 ||
> | 
Welcome $USER!
  | 
USER
 | 
not set
 | 
Welcome $USER!
 | Unset variables are not expanded. |
> | 
Welcome $USER2
 | 
USER2
   | 
USER2=John
 | 
Welcome John!
 ||
> | 
Welcome ${USER}2!
 | 
USER
  | 
USER=John
 | 
Welcome John2!
 ||
> | 
Welcome $USER-2!
 | 
USER
   | 
USER=John
 | 
Welcome John-2!
 ||
> | 
Welcome ${USER-2}!
 | 
USER-2
   | 
USER-2=John
 | 
Welcome John!
 | `USER-2` is likely to be an invalid env variable name, but jpackage launcher is not validating names. |
> 
> `$` character combination prevents variable expansion:
> | String    | Variables | Variable Values | Expanded String |
> | -------- | ------- |------- |------- |
> | 
Hello \$A! Bye $B
  | B | 
B=John
 | 
Hello $A! Bye John
 |
> | 
Hello \${A}! Bye $B
  | B | 
B=John
 | 
Hello ${A}! Bye John
 |
> 
> `\` character combination escapes ``:
> | String    | Variables | Variable Values | Expanded String |
> | -------- | ------- |------- |------- |
> | 
Hello \\\$A! Bye $B
  | A, B | 
A=Ana
B=John
 | 
Hello \\Ana! Bye John
 |
> 
> If `` character is not followed by another `` character or `$` character, it is interpreted as a regular character:
> | String    | Expanded string |
> | -------- | ------- |
> |
a\\b\\c
|
a\\b\\c
|
> 
> 
> Expansion is non-recursive:
> | String    | Variables | Variable Values | Expanded String | Note |
> | -------- | ------- |------- |------- |------- |
> | 
Hello $A!
  | A | 
A=$B
B=John
 | 
Hello $B
 | Variable "B" wi...

Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Update tests and implementation to comply with the CSR (env var names are case-insesitive on Windows)
 - Update help
 - Update src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/TokenReplace.java
   
   Co-authored-by: Andrey Turbanov 
 - Shorter test desc
 - A bit of javadoc
 - Update copyright year
 - Applied bin/blessed-modifier-order.sh
 - 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables available in *.cfg files
 - Moved $APPDIR, $BINDIR, and $ROOTDIR macros to JPackageCommand
 - Move token substitution in generic TokenReplace class.

-------------

Changes: https://git.openjdk.org/jdk/pull/23923/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23923&range=08
  Stats: 675 lines in 10 files changed: 627 ins; 10 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/23923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23923/head:pull/23923

PR: https://git.openjdk.org/jdk/pull/23923

From asemenyuk at openjdk.org  Wed Apr  9 20:56:03 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 9 Apr 2025 20:56:03 GMT
Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables
 available in *.cfg files [v10]
In-Reply-To: 
References: 
Message-ID: 

> jpackage app laucnher will expand environment variables in .cfg files.
> 
> Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and `$ROOTDIR` tokens with the corresponding path values. With this patch, any environment variable can be expanded. The syntax is shell-like `$ENV_VAR_NAME` or `${ENV_VAR_NAME}`. If `$ENV_VAR_NAME` syntax is used, the variable name stops at the first character outside of `[a-zA-Z0-9_]` character range. If `${ENV_VAR_NAME}` syntax is used, the variable name stops at the first `}` character after `${` substring. E.g:
> | String    | Variables | Variable Values | Expanded String | Note |
> | -------- | ------- |------- |------- |------- |
> | 
Welcome $USER!
  | 
USER
 | 
USER=John
 | 
Welcome John!
 ||
> | 
Welcome $USER!
  | 
USER
 | 
not set
 | 
Welcome $USER!
 | Unset variables are not expanded. |
> | 
Welcome $USER2
 | 
USER2
   | 
USER2=John
 | 
Welcome John!
 ||
> | 
Welcome ${USER}2!
 | 
USER
  | 
USER=John
 | 
Welcome John2!
 ||
> | 
Welcome $USER-2!
 | 
USER
   | 
USER=John
 | 
Welcome John-2!
 ||
> | 
Welcome ${USER-2}!
 | 
USER-2
   | 
USER-2=John
 | 
Welcome John!
 | `USER-2` is likely to be an invalid env variable name, but jpackage launcher is not validating names. |
> 
> `$` character combination prevents variable expansion:
> | String    | Variables | Variable Values | Expanded String |
> | -------- | ------- |------- |------- |
> | 
Hello \$A! Bye $B
  | B | 
B=John
 | 
Hello $A! Bye John
 |
> | 
Hello \${A}! Bye $B
  | B | 
B=John
 | 
Hello ${A}! Bye John
 |
> 
> `\` character combination escapes ``:
> | String    | Variables | Variable Values | Expanded String |
> | -------- | ------- |------- |------- |
> | 
Hello \\\$A! Bye $B
  | A, B | 
A=Ana
B=John
 | 
Hello \\Ana! Bye John
 |
> 
> If `` character is not followed by another `` character or `$` character, it is interpreted as a regular character:
> | String    | Expanded string |
> | -------- | ------- |
> |
a\\b\\c
|
a\\b\\c
|
> 
> 
> Expansion is non-recursive:
> | String    | Variables | Variable Values | Expanded String | Note |
> | -------- | ------- |------- |------- |------- |
> | 
Hello $A!
  | A | 
A=$B
B=John
 | 
Hello $B
 | Variable "B" wi...

Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Update tests and implementation to comply with the CSR (env var names are case-insesitive on Windows)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23923/files
  - new: https://git.openjdk.org/jdk/pull/23923/files/01270d3c..2b22c14d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23923&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23923&range=08-09

  Stats: 48 lines in 1 file changed: 8 ins; 14 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/23923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23923/head:pull/23923

PR: https://git.openjdk.org/jdk/pull/23923

From jlu at openjdk.org  Wed Apr  9 21:28:41 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 9 Apr 2025 21:28:41 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
Message-ID: 

On Wed, 9 Apr 2025 15:06:32 GMT, Magnus Ihse Bursie  wrote:

>> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Convert the merged master changes to UTF-8
>>  - Merge master and fix conflicts
>>  - Close streams when finished loading into props
>>  - Adjust CF test to read in with UTF-8 to fix failing test
>>  - Reconvert CS.properties to UTF-8
>>  - Revert all changes to CurrencySymbols.properties
>>  - Bug6204853 should not be converted
>>  - Copyright year for CompileProperties
>>  - Redo translation for CS.properties
>>  - Spot convert CurrencySymbols.properties
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a
>
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties line 22:
> 
>> 20: # Peter Smolik
>> 21: Cp1250 WINDOWS-1250 0x00FF
>> 22: # Patch attributed to havardw at underdusken.no (H?vard Wigtil)
> 
> This does not seem to have been a correct conversion.

Right, that `?` looks to have been incorrectly converted during the ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion as this change is from some time ago.)

Since the change occurs in a comment (thankfully), it should be harmless and the next upstream update of this file would overwrite this incorrect change. However, this file does not seem to be updated that often, so I can also file an issue to correct this if you would prefer that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036165417

From mdoerr at openjdk.org  Wed Apr  9 22:26:31 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 9 Apr 2025 22:26:31 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 4 Apr 2025 08:10:34 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 39 commits:
> 
>  - * missing file from merge
>  - 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 submit/8342382-card-table-instead-of-dcq
>  - * make young gen length revising independent of refinement thread
>      * use a service task
>      * both refinement control thread and young gen length revising use the same infrastructure to get the number of available bytes and determine the time to the next update
>  - * fix IR code generation tests that change due to barrier cost changes
>  - * factor out card table and refinement table merging into a single
>      method
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq3
>  - * obsolete G1UpdateBufferSize
>    
>    G1UpdateBufferSize has previously been used to size the refinement
>    buffers and impose a minimum limit on the number of cards per thread
>    that need to be pending before refinement starts.
>    
>    The former function is now obsolete with the removal of the dirty
>    card queues, the latter functionality has been taken over by the new
>    diagnostic option `G1PerThreadPendingCardThreshold`.
>    
>    I prefer to make this a diagnostic option is better than a product option
>    because it is something that is only necessary for some test cases to
>    produce some otherwise unwanted behavior (continuous refinement).
>    
>    CSR is pending.
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/41d4a0d7...1c5a669f

This PR needs an update for x86 platforms when merging: g1BarrierSetAssembler_x86.cpp:117:6: error: 'class MacroAssembler' has no member named 'get_thread'

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2791114662

From kbarrett at openjdk.org  Wed Apr  9 22:36:26 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 9 Apr 2025 22:36:26 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 9 Apr 2025 19:54:55 GMT, Brent Christian  wrote:

>> Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead to intermittent test failures ([JDK-8298783](https://bugs.openjdk.org/browse/JDK-8298783)  is a recent example).
>> 
>> A better mechanism already exists in the private `Reference.waitForReferenceProcessing()` method. This PR makes `waitForReferenceProcessing()` available to tests via the `WhiteBox` and `ForceGC` test libraries.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   only add wFRP to WhiteBox for now

test/lib/jdk/test/whitebox/WhiteBox.java line 574:

> 572:         Class refClass = Class.forName("java.lang.ref.Reference");
> 573:         Method[] methods = refClass.getDeclaredMethods();
> 574:         wfrp = Arrays.stream(methods).filter((m) -> m.getName().equals("waitForReferenceProcessing")).findFirst().get();

Use `getDeclaredMethod`, as previously suggested by @RogerRiggs in comment for the copy in ForceGC?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2036226745

From asemenyuk at openjdk.org  Wed Apr  9 22:42:27 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 9 Apr 2025 22:42:27 GMT
Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables
 available in *.cfg files
In-Reply-To: 
References: 
 
Message-ID: <_5Aw4ExgTZ_FHe20PRT99aRLmHddzZg2veBqA-bXle4=.16de7f87-6db0-4a02-87b4-777f107a285e@github.com>

On Thu, 6 Mar 2025 02:18:56 GMT, Alexander Matveev  wrote:

>> jpackage app laucnher will expand environment variables in .cfg files.
>> 
>> Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and `$ROOTDIR` tokens with the corresponding path values. With this patch, any environment variable can be expanded. The syntax is shell-like `$ENV_VAR_NAME` or `${ENV_VAR_NAME}`. If `$ENV_VAR_NAME` syntax is used, the variable name stops at the first character outside of `[a-zA-Z0-9_]` character range. If `${ENV_VAR_NAME}` syntax is used, the variable name stops at the first `}` character after `${` substring. E.g:
>> | String    | Variables | Variable Values | Expanded String | Note |
>> | -------- | ------- |------- |------- |------- |
>> | 
Welcome $USER!
  | 
USER
 | 
USER=John
 | 
Welcome John!
 ||
>> | 
Welcome $USER!
  | 
USER
 | 
not set
 | 
Welcome $USER!
 | Unset variables are not expanded. |
>> | 
Welcome $USER2
 | 
USER2
   | 
USER2=John
 | 
Welcome John!
 ||
>> | 
Welcome ${USER}2!
 | 
USER
  | 
USER=John
 | 
Welcome John2!
 ||
>> | 
Welcome $USER-2!
 | 
USER
   | 
USER=John
 | 
Welcome John-2!
 ||
>> | 
Welcome ${USER-2}!
 | 
USER-2
   | 
USER-2=John
 | 
Welcome John!
 | `USER-2` is likely to be an invalid env variable name, but jpackage launcher is not validating names. |
>> 
>> `$` character combination prevents variable expansion:
>> | String    | Variables | Variable Values | Expanded String |
>> | -------- | ------- |------- |------- |
>> | 
Hello \$A! Bye $B
  | B | 
B=John
 | 
Hello $A! Bye John
 |
>> | 
Hello \${A}! Bye $B
  | B | 
B=John
 | 
Hello ${A}! Bye John
 |
>> 
>> `\` character combination escapes ``:
>> | String    | Variables | Variable Values | Expanded String |
>> | -------- | ------- |------- |------- |
>> | 
Hello \\\$A! Bye $B
  | A, B | 
A=Ana
B=John
 | 
Hello \\Ana! Bye John
 |
>> 
>> If `` character is not followed by another `` character or `$` character, it is interpreted as a regular character:
>> | String    | Expanded string |
>> | -------- | ------- |
>> |
a\\b\\c
|
a\\b\\c
|
>> 
>> 
>> Expansion is non-recursive:
>> | String    | Variables | Variable Values | Expanded String | Note |
>> | -------- | ------- |------- |------- |------- |
>> | 
Hello $A!
  | A | 
A...
>
> If you do `echo` on macOS in terminal for unset variable it will be expanded to `empty string`, so for `"Unset variables are not expanded."` should we have `Welcome !` instead of `Welcome $USER!`?

Updated the implementation and tests to comply with the CSR. @sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23923#issuecomment-2791134989

From liangchenblue at gmail.com  Wed Apr  9 22:45:56 2025
From: liangchenblue at gmail.com (Chen Liang)
Date: Wed, 9 Apr 2025 17:45:56 -0500
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: <3f1c69a7ac5946809d2af850d7d59db9@amazon.com>
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 
 <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 
 
 <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
 
 <3f1c69a7ac5946809d2af850d7d59db9@amazon.com>
Message-ID: 

Hi John Engebretson,
I still wonder if we can make the byte array allocator a utility to the
JDK, at least an internal one. I find that besides replacing BAOS uses, it
can also optimize users like InputStream.readNBytes, BufWriterImpl of
classfile, and maybe many more usages. Such an internal addition may be
accepted to the JDK immediately because it has no compatibility impact and
does not need to undergo CSR review.

Chen Liang

On Wed, Apr 9, 2025 at 11:35?AM Engebretson, John 
wrote:

> I think there is agreement that ByteArrayOutputStream.unsynchronized(int
> cap) (or some such method) would be useful. It would not require using a
> contiguous byte[] as the backing array so there is scope to experiment with
> implementations that don't need to resize like the base BAOS does.
>
> Extending BOAS means the size is limited to an int. To go beyond would be
> a different API and there is lots of scope to do experiments. I think too
> early to create a CSR for MOS, assuming this is what you mean.
>
>   Thank you Alan!  PR [1] is updated with the factory method as suggested;
> MOS is a package-private subclass of BAOS and the Javadoc in BAOS makes no
> promises about the implementation returned.  I allowed MOS to grow beyond
> 2GB and throw an intelligent error if it cannot service a particular call
> (toByteArray, size, etc.).  Performance is unchanged.  Feedback appreciated.
>
>   Thanks!  ?
>
>      John
>
>
>
> [1] https://github.com/openjdk/jdk/pull/24232
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From liach at openjdk.org  Wed Apr  9 22:59:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 22:59:27 GMT
Subject: RFR: 8352748: Remove com.sun.tools.classfile from the JDK [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 9 Apr 2025 15:04:24 GMT, Chen Liang  wrote:

>> With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.
>> 
>> Testing: built locally, running tier 1-3 tests
>> 
>> Don't know why, but GitHub is redundantly displaying changes that are already in #24212.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
>  - 8352748: Remove com.sun.tools.classfile from the JDK
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - Other references to remove
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - FieldDescription.constantValue uses Integer for byte and short
>  - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

Tier 1-3 tests all pass. Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24528#issuecomment-2791008239

From liach at openjdk.org  Wed Apr  9 23:02:34 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 23:02:34 GMT
Subject: Integrated: 8352748: Remove com.sun.tools.classfile from the JDK
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 20:34:09 GMT, Chen Liang  wrote:

> With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.
> 
> Testing: built locally, running tier 1-3 tests
> 
> Don't know why, but GitHub is redundantly displaying changes that are already in #24212.

This pull request has now been integrated.

Changeset: 5c438c5e
Author:    Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/5c438c5e6b636a7992cbd737de0735070e480061
Stats:     10015 lines in 70 files changed: 0 ins; 10009 del; 6 mod

8352748: Remove com.sun.tools.classfile from the JDK

Reviewed-by: ihse, jlahoda, vromero

-------------

PR: https://git.openjdk.org/jdk/pull/24528

From bchristi at openjdk.org  Wed Apr  9 23:12:00 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 9 Apr 2025 23:12:00 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v3]
In-Reply-To: 
References: 
Message-ID: 

> Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead to intermittent test failures ([JDK-8298783](https://bugs.openjdk.org/browse/JDK-8298783)  is a recent example).
> 
> A better mechanism already exists in the private `Reference.waitForReferenceProcessing()` method. This PR makes `waitForReferenceProcessing()` available to tests via the `WhiteBox` and `ForceGC` test libraries.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  reflection improvements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24527/files
  - new: https://git.openjdk.org/jdk/pull/24527/files/f665678f..4b838e7a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24527&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24527&range=01-02

  Stats: 10 lines in 1 file changed: 1 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24527/head:pull/24527

PR: https://git.openjdk.org/jdk/pull/24527

From bchristi at openjdk.org  Wed Apr  9 23:12:00 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 9 Apr 2025 23:12:00 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v3]
In-Reply-To: 
References: 
 
Message-ID: <8I70uGa66nY8kxyEYuIATozZVTlYVsG1o46U5iswSI0=.99180746-f40d-4420-8760-1bb202f6a009@github.com>

On Tue, 8 Apr 2025 21:16:22 GMT, Roger Riggs  wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reflection improvements
>
> test/lib/jdk/test/lib/util/ForceGC.java line 125:
> 
>> 123:                 Method[] methods = refClass.getDeclaredMethods();
>> 124:                 wfrp = Arrays.stream(methods).filter((m) -> m.getName().equals("waitForReferenceProcessing")).findFirst().get();
>> 125:                 wfrp.setAccessible(true);
> 
> You don't need the stream.  
> Suggestion:
> 
>                 Method wfrp = Reference.class.getDeclaredMethod("waitForReferenceProcessing");
>                 wfrp.setAccessible(true);

Yes, that is better, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2036252717

From bchristi at openjdk.org  Wed Apr  9 23:12:01 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 9 Apr 2025 23:12:01 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <4pq3zDXNYeWcSGVzjlSfCLqhhUEjGzVxEJTXpxLlRdY=.662539ef-8487-44b6-87f9-cf4bb6ee3dd9@github.com>

On Wed, 9 Apr 2025 22:34:13 GMT, Kim Barrett  wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   only add wFRP to WhiteBox for now
>
> test/lib/jdk/test/whitebox/WhiteBox.java line 574:
> 
>> 572:         Class refClass = Class.forName("java.lang.ref.Reference");
>> 573:         Method[] methods = refClass.getDeclaredMethods();
>> 574:         wfrp = Arrays.stream(methods).filter((m) -> m.getName().equals("waitForReferenceProcessing")).findFirst().get();
> 
> Use `getDeclaredMethod`, as previously suggested by @RogerRiggs in comment for the copy in ForceGC?

Yep

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2036253459

From jlahoda at openjdk.org  Thu Apr 10 01:03:01 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 10 Apr 2025 01:03:01 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v4]
In-Reply-To: 
References: 
Message-ID: 

> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
> - `java. ... .IO` is no longer automatically imported in any compilation unit
> - the feature is finalized (i.e. no longer requires `--enable-preview`)

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Add clause about handling of malformed/unmappable bytes.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24438/files
  - new: https://git.openjdk.org/jdk/pull/24438/files/33e280df..05cc336e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=02-03

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24438.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24438/head:pull/24438

PR: https://git.openjdk.org/jdk/pull/24438

From smarks at openjdk.org  Thu Apr 10 01:06:43 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 10 Apr 2025 01:06:43 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v4]
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: <2WoKJPTnP6NRxytTHtqJoi_8b-gAT1vd3YgO2swg_9U=.69c3746e-97cc-485e-8742-b92c1fbc4367@github.com>

On Wed, 9 Apr 2025 17:02:52 GMT, Stuart Marks  wrote:

>> The readln methods handle malformed-input and unmappable-character errors by dropping, and using a replacement value. So erroneous input doesn't throw IOError with a CharacterCodingException as the cause.
>> 
>> System.in.close() would a be wild thing to do, but a case where readln would throw IOError.
>
> Ah. Does the specification here need to state the policy around malformed input and unmappable characters? (Or, maybe in the class specification.)
> 
> People have ended up in cases where System.in is closed. It can occur when combining use of Scanner to read from System.in and applying the anything-that-you-open-must-be-closed rule, e.g.,
> 
>     try (Scanner sc = new Scanner(System.in)) {
>         String s = sc.nextLine();
>     }
> 
> which is a mistake, but it takes a long time to explain....

I added a clause to the class specification that covers malformed/unmappable byte sequences.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2036340667

From almatvee at openjdk.org  Thu Apr 10 01:35:45 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 10 Apr 2025 01:35:45 GMT
Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables
 available in *.cfg files [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 9 Apr 2025 20:56:03 GMT, Alexey Semenyuk  wrote:

>> jpackage app laucnher will expand environment variables in .cfg files.
>> 
>> Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and `$ROOTDIR` tokens with the corresponding path values. With this patch, any environment variable can be expanded. The syntax is shell-like `$ENV_VAR_NAME` or `${ENV_VAR_NAME}`. If `$ENV_VAR_NAME` syntax is used, the variable name stops at the first character outside of `[a-zA-Z0-9_]` character range. If `${ENV_VAR_NAME}` syntax is used, the variable name stops at the first `}` character after `${` substring. E.g:
>> | String    | Variables | Variable Values | Expanded String | Note |
>> | -------- | ------- |------- |------- |------- |
>> | 
Welcome $USER!
  | 
USER
 | 
USER=John
 | 
Welcome John!
 ||
>> | 
Welcome $USER!
  | 
USER
 | 
not set
 | 
Welcome $USER!
 | Unset variables are not expanded. |
>> | 
Welcome $USER2
 | 
USER2
   | 
USER2=John
 | 
Welcome John!
 ||
>> | 
Welcome ${USER}2!
 | 
USER
  | 
USER=John
 | 
Welcome John2!
 ||
>> | 
Welcome $USER-2!
 | 
USER
   | 
USER=John
 | 
Welcome John-2!
 ||
>> | 
Welcome ${USER-2}!
 | 
USER-2
   | 
USER-2=John
 | 
Welcome John!
 | `USER-2` is likely to be an invalid env variable name, but jpackage launcher is not validating names. |
>> 
>> `$` character combination prevents variable expansion:
>> | String    | Variables | Variable Values | Expanded String |
>> | -------- | ------- |------- |------- |
>> | 
Hello \$A! Bye $B
  | B | 
B=John
 | 
Hello $A! Bye John
 |
>> | 
Hello \${A}! Bye $B
  | B | 
B=John
 | 
Hello ${A}! Bye John
 |
>> 
>> `\` character combination escapes ``:
>> | String    | Variables | Variable Values | Expanded String |
>> | -------- | ------- |------- |------- |
>> | 
Hello \\\$A! Bye $B
  | A, B | 
A=Ana
B=John
 | 
Hello \\Ana! Bye John
 |
>> 
>> If `` character is not followed by another `` character or `$` character, it is interpreted as a regular character:
>> | String    | Expanded string |
>> | -------- | ------- |
>> |
a\\b\\c
|
a\\b\\c
|
>> 
>> 
>> Expansion is non-recursive:
>> | String    | Variables | Variable Values | Expanded String | Note |
>> | -------- | ------- |------- |------- |------- |
>> | 
Hello $A!
  | A | 
A...
>
> Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Update tests and implementation to comply with the CSR (env var names are case-insesitive on Windows)

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23923#pullrequestreview-2755122528

From archie.cobbs at gmail.com  Thu Apr 10 01:38:24 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Wed, 9 Apr 2025 20:38:24 -0500
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: 
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 
 <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 
 
 <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
 
 <3f1c69a7ac5946809d2af850d7d59db9@amazon.com>
 
Message-ID: 

At the risk of repeating my previous comment
,
I agree with Chen.

That is to say, there is a separate, more fundamental unsolved problem
lurking underneath this discussion, and the two problem "layers" are
perhaps better addressed separately.

Once the lower layer problem is properly framed and resolved, it becomes
reusable, and wrapping it to solve various higher-layer problems is easy.

An internal class would be a reasonable and conservative way to start.
There could even be a suite of such classes, built from templates a la
X-Buffer.java.template.

These could be used all over the place (e.g., refactor StringBuilder). For
example, I wonder how much the performance of e.g. ArrayList could be
improved in scenarios where you are building (or removing elements from)
large lists?

Just thinking out loud (apologies)... Define a "segmented array allocator"
as an in-memory byte[] array builder that "chunks" the data into individual
segments of size at most N.

We can think of the current ByteArrayOutputStream as such a thing with N =
2?? that is, there's only ever one "chunk".

The assertion is that N = 2?? is not the most efficient value. And
obviously neither is N = 1.

So somewhere in the middle there is an optimal value for N, which
presumably could be discovered via experimentation. It may be different for
different architectures.

Another parameter would be: What is the size M ? N of a new chunk? E.g. you
could start with M = 16 and then the chunk grows exponentially until it
reaches N, at which point you start a new chunk. The optimal value for M
could also be performance tested (it may already have been).

Of course, for performance optimization we'd need some distribution of
array sizes that models "typical" use, etc.

-Archie

On Wed, Apr 9, 2025 at 6:19?PM Chen Liang  wrote:

> Hi John Engebretson,
> I still wonder if we can make the byte array allocator a utility to the
> JDK, at least an internal one. I find that besides replacing BAOS uses, it
> can also optimize users like InputStream.readNBytes, BufWriterImpl of
> classfile, and maybe many more usages. Such an internal addition may be
> accepted to the JDK immediately because it has no compatibility impact and
> does not need to undergo CSR review.
>
> Chen Liang
>
> On Wed, Apr 9, 2025 at 11:35?AM Engebretson, John 
> wrote:
>
>> I think there is agreement that ByteArrayOutputStream.unsynchronized(int
>> cap) (or some such method) would be useful. It would not require using a
>> contiguous byte[] as the backing array so there is scope to experiment with
>> implementations that don't need to resize like the base BAOS does.
>>
>> Extending BOAS means the size is limited to an int. To go beyond would be
>> a different API and there is lots of scope to do experiments. I think too
>> early to create a CSR for MOS, assuming this is what you mean.
>>
>>   Thank you Alan!  PR [1] is updated with the factory method as
>> suggested; MOS is a package-private subclass of BAOS and the Javadoc in
>> BAOS makes no promises about the implementation returned.  I allowed MOS to
>> grow beyond 2GB and throw an intelligent error if it cannot service a
>> particular call (toByteArray, size, etc.).  Performance is unchanged.
>> Feedback appreciated.
>>
>>   Thanks!  ?
>>
>>      John
>>
>>
>>
>> [1] https://github.com/openjdk/jdk/pull/24232
>>
>>
>>
>

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From asemenyuk at openjdk.org  Thu Apr 10 01:41:43 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 10 Apr 2025 01:41:43 GMT
Subject: Integrated: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables
 available in *.cfg files
In-Reply-To: 
References: 
Message-ID: 

On Wed, 5 Mar 2025 21:13:44 GMT, Alexey Semenyuk  wrote:

> jpackage app laucnher will expand environment variables in .cfg files.
> 
> Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and `$ROOTDIR` tokens with the corresponding path values. With this patch, any environment variable can be expanded. The syntax is shell-like `$ENV_VAR_NAME` or `${ENV_VAR_NAME}`. If `$ENV_VAR_NAME` syntax is used, the variable name stops at the first character outside of `[a-zA-Z0-9_]` character range. If `${ENV_VAR_NAME}` syntax is used, the variable name stops at the first `}` character after `${` substring. E.g:
> | String    | Variables | Variable Values | Expanded String | Note |
> | -------- | ------- |------- |------- |------- |
> | 
Welcome $USER!
  | 
USER
 | 
USER=John
 | 
Welcome John!
 ||
> | 
Welcome $USER!
  | 
USER
 | 
not set
 | 
Welcome $USER!
 | Unset variables are not expanded. |
> | 
Welcome $USER2
 | 
USER2
   | 
USER2=John
 | 
Welcome John!
 ||
> | 
Welcome ${USER}2!
 | 
USER
  | 
USER=John
 | 
Welcome John2!
 ||
> | 
Welcome $USER-2!
 | 
USER
   | 
USER=John
 | 
Welcome John-2!
 ||
> | 
Welcome ${USER-2}!
 | 
USER-2
   | 
USER-2=John
 | 
Welcome John!
 | `USER-2` is likely to be an invalid env variable name, but jpackage launcher is not validating names. |
> 
> `$` character combination prevents variable expansion:
> | String    | Variables | Variable Values | Expanded String |
> | -------- | ------- |------- |------- |
> | 
Hello \$A! Bye $B
  | B | 
B=John
 | 
Hello $A! Bye John
 |
> | 
Hello \${A}! Bye $B
  | B | 
B=John
 | 
Hello ${A}! Bye John
 |
> 
> `\` character combination escapes ``:
> | String    | Variables | Variable Values | Expanded String |
> | -------- | ------- |------- |------- |
> | 
Hello \\\$A! Bye $B
  | A, B | 
A=Ana
B=John
 | 
Hello \\Ana! Bye John
 |
> 
> If `` character is not followed by another `` character or `$` character, it is interpreted as a regular character:
> | String    | Expanded string |
> | -------- | ------- |
> |
a\\b\\c
|
a\\b\\c
|
> 
> 
> Expansion is non-recursive:
> | String    | Variables | Variable Values | Expanded String | Note |
> | -------- | ------- |------- |------- |------- |
> | 
Hello $A!
  | A | 
A=$B
B=John
 | 
Hello $B
 | Variable "B" wi...

This pull request has now been integrated.

Changeset: 45b7c748
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/45b7c748737f38c33c4666d17101b051b2fbe2ae
Stats:     669 lines in 10 files changed: 621 ins; 10 del; 38 mod

8341641: Make %APPDATA% and %LOCALAPPDATA% env variables available in *.cfg files

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/23923

From fyang at openjdk.org  Thu Apr 10 02:16:36 2025
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 10 Apr 2025 02:16:36 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v3]
In-Reply-To: <5sujqD7L_cmLUyDwYb4PhgOlEeiFwlkAV7RJoVMFTrM=.223437cd-bbb2-4ef3-a6fe-b13ce402e14b@github.com>
References: 
 <5sujqD7L_cmLUyDwYb4PhgOlEeiFwlkAV7RJoVMFTrM=.223437cd-bbb2-4ef3-a6fe-b13ce402e14b@github.com>
Message-ID: 

On Mon, 31 Mar 2025 10:45:54 GMT, Robbin Ehn  wrote:

>> Hi, for you to consider.
>> 
>> These tests constantly fails in qemu-user.
>> Either the require host to be same arch explicit or implicit (sysroot).
>> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'" for SA tests.
>> 
>> From bug:
>>> qemu-user/rv64 sets uarch to "qemu" in /proc/cpuinfo (qemu-system do not do that).
>>> We add this uarch to CPU feature string.
>>> This means we can use jtreg 'require' with cpu string to filter out tests in qemu-user.
>> 
>> Relevant qemu code:
>> https://github.com/qemu/qemu/blob/170825d14d88a1ce7fae98d5a928480f2f329b22/linux-user/riscv/target_proc.h#L29
>> 
>> Relevant hotspot code:
>> https://github.com/openjdk/jdk/blob/fa0b18bfde38ee2ffbab33a9eaac547fe8aa3c7c/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L250
>> 
>> Tested that the require only filters out tests in qemu+riscv64.
>> 
>> Thanks!
>> 
>> /Robbin
>
> Robbin Ehn 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' into qemu-user-issues
>  - Revert
>  - Merge branch 'master' into qemu-user-issues
>  - Merge branch 'master' into qemu-user-issues
>  - more
>  - more
>  - native or very long

> qemu-user, "uarch: qemu" in cpuinfo: `[0.084s][info ][os,cpu] CPU: total 28 (initial active 28) qemu rv64 rvi rvm rva rvf rvd rvc rvv zba zbb zbs zfh zfhmin zvbc zvfh zicond` Hence we know this is qemu-user (only qemu-user sets uarch to qemu on riscv).
> 
> `/proc/cpuinfo` do not contain uarch: [0.053s][info ][os,cpu] CPU: total 8 (initial active 8) rv64 rvi rvm rva rvf rvd rvc zba zbb zbs zfh zfhmin zvfh zicond We have no clue if this is emulated or on real hardware, tests will be executed.
> 
> Tests are only excluded if we know it's qemu-user.


> qemu-user, "uarch: qemu" in cpuinfo: `[0.084s][info ][os,cpu] CPU: total 28 (initial active 28) qemu rv64 rvi rvm rva rvf rvd rvc rvv zba zbb zbs zfh zfhmin zvbc zvfh zicond` Hence we know this is qemu-user (only qemu-user sets uarch to qemu on riscv).
> 
> `/proc/cpuinfo` do not contain uarch: [0.053s][info ][os,cpu] CPU: total 8 (initial active 8) rv64 rvi rvm rva rvf rvd rvc zba zbb zbs zfh zfhmin zvfh zicond We have no clue if this is emulated or on real hardware, tests will be executed.
> 
> Tests are only excluded if we know it's qemu-user.

Sorry for not being clear enough. Yes, that's how it works with qemu-user for riscv.
Just wondering if it makes sense to extend this to other CPU platforms. There are two cases.
- Case 1: The tests are excluded as expected if we parses "qemu" in cpuinfo with qemu-user for another CPU, which is simiar with qemu-user for riscv. But I am not sure if there is one for now.
- Case 2: The tests are NOT excluded as there's no "qemu" in cpuinfo with qemu-user for another CPU. Then we still got test failures as before. But we are not causing any more regressions. I may consider that as a qemu-user issue for this CPU. And it could be fixed on the qemu-user side if it really helps people.

Maybe I am demanding too much about qemu-user. What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2791376594

From pminborg at openjdk.org  Thu Apr 10 06:00:48 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 10 Apr 2025 06:00:48 GMT
Subject: RFR: 8350075: Performance difference between SegmentAllocator
 methods [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposes to add `@ForceInline` to the `default` methods in `SegmentAllocator` that do not already have it.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Add benchmark
 - Merge branch 'master' into ms-add-missing-force-inline
 - Add @ForceInline to default methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23628/files
  - new: https://git.openjdk.org/jdk/pull/23628/files/a4be5572..8b44d78d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23628&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23628&range=00-01

  Stats: 195415 lines in 4444 files changed: 89076 ins; 81873 del; 24466 mod
  Patch: https://git.openjdk.org/jdk/pull/23628.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23628/head:pull/23628

PR: https://git.openjdk.org/jdk/pull/23628

From swen at openjdk.org  Thu Apr 10 06:00:26 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 10 Apr 2025 06:00:26 GMT
Subject: RFR: 8353741: Improve UUID.toString performance by using SIMD
 within a register instead of table lookup [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <2rKVjErLqd0ArfsMehwla1-ole7MNZrZhqBsuovhTmc=.2f358170-04a0-4da3-be7d-0a6c33612ade@github.com>

On Tue, 8 Apr 2025 18:04:43 GMT, Johannes Graham  wrote:

> Have you considered removing `reverseBytes` and using `ByteArray` instead of `ByteArrayLittleEndian`?

I tested it on a MacBook M1 Max, and the performance of using reverseBytes + ByteArrayLittleEndian is about 1% faster. Considering that most of us have little-endian machines, ByteArray.setInt/setLong also needs to do reverseBytes.

Doing reverseBytes in hex8 requires 4 Long.reverseBytes in a UUID.toString call. If using ByteArray, on a little-endian machine, a UUID.toString call requires 2 Long.reverseBytes and 4 Integer.reverseBytes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22928#issuecomment-2791638162

From pminborg at openjdk.org  Thu Apr 10 06:00:48 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 10 Apr 2025 06:00:48 GMT
Subject: RFR: 8350075: Performance difference between SegmentAllocator
 methods
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 Feb 2025 09:19:35 GMT, Per Minborg  wrote:

> This PR proposes to add `@ForceInline` to the `default` methods in `SegmentAllocator` that do not already have it.

Base:


Benchmark                     Mode  Cnt          Score          Error  Units
AllocFromInlineTest.alloc00  thrpt    6  476452588.661 ?  7278882.517  ops/s
AllocFromInlineTest.alloc01  thrpt    6  478294334.573 ? 12849151.248  ops/s
AllocFromInlineTest.alloc02  thrpt    6  478719668.816 ? 15861024.634  ops/s
AllocFromInlineTest.alloc03  thrpt    6  478346000.607 ?  8894248.371  ops/s
AllocFromInlineTest.alloc04  thrpt    6  477480288.497 ? 24475377.961  ops/s
AllocFromInlineTest.alloc05  thrpt    6  478981910.741 ? 10047783.948  ops/s
AllocFromInlineTest.alloc06  thrpt    6  479300719.724 ? 14778024.488  ops/s
AllocFromInlineTest.alloc07  thrpt    6  480071960.165 ? 13141382.801  ops/s
AllocFromInlineTest.alloc08  thrpt    6  370508102.298 ? 15769922.608  ops/s
AllocFromInlineTest.alloc09  thrpt    6  282440969.138 ?  7061789.415  ops/s
AllocFromInlineTest.alloc10  thrpt    6  270971705.049 ?  7088889.559  ops/s
AllocFromInlineTest.alloc11  thrpt    6  269216600.688 ? 11097251.197  ops/s
AllocFromInlineTest.alloc12  thrpt    6  155310245.753 ?  2901522.195  ops/s
AllocFromInlineTest.alloc13  thrpt    6  155960685.355 ?  3753241.849  ops/s
AllocFromInlineTest.alloc14  thrpt    6  158746683.590 ?  1405113.930  ops/s
AllocFromInlineTest.alloc15  thrpt    6  133846753.437 ?   110295.996  ops/s


Patch:


Benchmark                     Mode  Cnt          Score          Error  Units
AllocFromInlineTest.alloc00  thrpt    6  470486588.500 ? 19222697.340  ops/s
AllocFromInlineTest.alloc01  thrpt    6  476866882.368 ? 18330599.542  ops/s
AllocFromInlineTest.alloc02  thrpt    6  480518760.561 ? 10645063.162  ops/s
AllocFromInlineTest.alloc03  thrpt    6  479862457.027 ? 12991374.677  ops/s
AllocFromInlineTest.alloc04  thrpt    6  480432586.862 ? 11229500.034  ops/s
AllocFromInlineTest.alloc05  thrpt    6  480723976.385 ?  7744771.142  ops/s
AllocFromInlineTest.alloc06  thrpt    6  481476767.735 ? 13672690.226  ops/s
AllocFromInlineTest.alloc07  thrpt    6  478505354.988 ?  9564577.750  ops/s
AllocFromInlineTest.alloc08  thrpt    6  369357735.209 ? 11653294.244  ops/s
AllocFromInlineTest.alloc09  thrpt    6  281708677.332 ? 10404941.019  ops/s
AllocFromInlineTest.alloc10  thrpt    6  271084202.621 ?  7437750.547  ops/s
AllocFromInlineTest.alloc11  thrpt    6  271395930.818 ?  6696736.324  ops/s
AllocFromInlineTest.alloc12  thrpt    6  156745633.040 ?  4996616.105  ops/s
AllocFromInlineTest.alloc13  thrpt    6  157755346.229 ?  4991249.264  ops/s
AllocFromInlineTest.alloc14  thrpt    6  154167559.599 ?  2733281.193  ops/s
AllocFromInlineTest.alloc15  thrpt    6  157332555.961 ?  2915557.625  ops/s 


Log output shows for `alloc15`:

Base:


                              @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_15 (5 bytes)   inline (hot)
                                @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_14 (5 bytes)   inline (hot)
                                  @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_13 (5 bytes)   inline (hot)
                                    @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_12 (5 bytes)   inline (hot)
                                      @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_11 (5 bytes)   inline (hot)
                                        @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_10 (5 bytes)   inline (hot)
                                          @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_9 (5 bytes)   inline (hot)
                                            @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_8 (5 bytes)   inline (hot)
                                              @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_7 (5 bytes)   inline (hot)
                                                @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_6 (5 bytes)   inline (hot)
                                                  @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_5 (5 bytes)   inline (hot)
                                                    @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_4 (5 bytes)   inline (hot)
                                                      @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_3 (5 bytes)   inline (hot)
                                                        @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_2 (5 bytes)   inline (hot)
                                                          @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_1 (5 bytes)   inline (hot)
                                                            @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_0 (14 bytes)   inline (hot)
                                                              @ 8   java.lang.foreign.SegmentAllocator::allocateFrom (24 bytes)   failed to inline: inlining too deep


Patch:


                              @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_15 (5 bytes)   inline (hot)
                                @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_14 (5 bytes)   inline (hot)
                                  @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_13 (5 bytes)   inline (hot)
                                    @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_12 (5 bytes)   inline (hot)
                                      @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_11 (5 bytes)   inline (hot)
                                        @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_10 (5 bytes)   inline (hot)
                                          @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_9 (5 bytes)   inline (hot)
                                            @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_8 (5 bytes)   inline (hot)
                                              @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_7 (5 bytes)   inline (hot)
                                                @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_6 (5 bytes)   inline (hot)
                                                  @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_5 (5 bytes)   inline (hot)
                                                    @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_4 (5 bytes)   inline (hot)
                                                      @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_3 (5 bytes)   inline (hot)
                                                        @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_2 (5 bytes)   inline (hot)
                                                          @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_1 (5 bytes)   inline (hot)
                                                            @ 1   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest::alloc_0 (14 bytes)   inline (hot)
                                                              @ 8   java.lang.foreign.SegmentAllocator::allocateFrom (24 bytes)   force inline by annotation   late inline succeeded
                                                                @ 1   java.util.Objects::requireNonNull (14 bytes)   force inline by annotation
                                                                @ 7   java.lang.foreign.SegmentAllocator::allocateNoInit (41 bytes)   force inline by annotation
                                                                  @ 35   java.lang.foreign.SegmentAllocator::allocate (24 bytes)   force inline by annotation
                                                                    @ 1   java.util.Objects::requireNonNull (14 bytes)   force inline by annotation
                                                                    @ 7   jdk.internal.foreign.layout.AbstractLayout::byteSize (5 bytes)   accessor
                                                                    @ 13   jdk.internal.foreign.layout.AbstractLayout::byteAlignment (5 bytes)   accessor
                                                                    @ 18   org.openjdk.bench.java.lang.foreign.AllocFromInlineTest$FakeArena::allocate (5 bytes)   failed to inline: inlining too deep


So, with the patch, we can inline in a similar way as the other `default` methods already annotated with `@ForceInline`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23628#issuecomment-2791638448

From pminborg at openjdk.org  Thu Apr 10 06:34:24 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 10 Apr 2025 06:34:24 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v52]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 307 commits:

 - Fix typo
 - Merge branch 'master' into implement-jep502
 - Fix typo in return type
 - Change double to int
 - Fix typo
 - Update examples
 - Remove parantheses
 - Only use partial functions
 - Fix typo
 - Add note an partial and total functions
 - ... and 297 more: https://git.openjdk.org/jdk/compare/250eb743...9c7b48b7

-------------

Changes: https://git.openjdk.org/jdk/pull/23972/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=51
  Stats: 4596 lines in 30 files changed: 4574 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From pminborg at openjdk.org  Thu Apr 10 06:34:25 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 10 Apr 2025 06:34:25 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v51]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 9 Apr 2025 17:17:01 GMT, R?mi Forax  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in return type
>
> src/java.base/share/classes/java/lang/StableValue.java line 397:
> 
>> 395:  * collections are built on top of StableValue. As such, they are also treated as
>> 396:  * constants by the JFM.
>> 397:  * 

> 
> JFM -> JVM

German pronunciation ...  Jokes aside, thanks for spotting this typo.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2036601822

From rehn at openjdk.org  Thu Apr 10 07:08:39 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 10 Apr 2025 07:08:39 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v3]
In-Reply-To: 
References: 
 <5sujqD7L_cmLUyDwYb4PhgOlEeiFwlkAV7RJoVMFTrM=.223437cd-bbb2-4ef3-a6fe-b13ce402e14b@github.com>
 
Message-ID: 

On Thu, 10 Apr 2025 02:13:46 GMT, Fei Yang  wrote:

> > qemu-user, "uarch: qemu" in cpuinfo: `[0.084s][info ][os,cpu] CPU: total 28 (initial active 28) qemu rv64 rvi rvm rva rvf rvd rvc rvv zba zbb zbs zfh zfhmin zvbc zvfh zicond` Hence we know this is qemu-user (only qemu-user sets uarch to qemu on riscv).
> > `/proc/cpuinfo` do not contain uarch: [0.053s][info ][os,cpu] CPU: total 8 (initial active 8) rv64 rvi rvm rva rvf rvd rvc zba zbb zbs zfh zfhmin zvfh zicond We have no clue if this is emulated or on real hardware, tests will be executed.
> > Tests are only excluded if we know it's qemu-user.
> 
> > qemu-user, "uarch: qemu" in cpuinfo: `[0.084s][info ][os,cpu] CPU: total 28 (initial active 28) qemu rv64 rvi rvm rva rvf rvd rvc rvv zba zbb zbs zfh zfhmin zvbc zvfh zicond` Hence we know this is qemu-user (only qemu-user sets uarch to qemu on riscv).
> > `/proc/cpuinfo` do not contain uarch: [0.053s][info ][os,cpu] CPU: total 8 (initial active 8) rv64 rvi rvm rva rvf rvd rvc zba zbb zbs zfh zfhmin zvfh zicond We have no clue if this is emulated or on real hardware, tests will be executed.
> > Tests are only excluded if we know it's qemu-user.
> 
> Sorry for not being clear enough. Yes, that's how it works with qemu-user for riscv. Just wondering if it makes sense to extend this to other CPU platforms. There are two cases.
> 
> * Case 1: The tests are excluded as expected if we parses "qemu" in cpuinfo with qemu-user for another CPU, which is simiar with qemu-user for riscv. But I am not sure if there is one for now.
> * Case 2: The tests are NOT excluded as there's no "qemu" in cpuinfo with qemu-user for another CPU. Then we still got test failures as before. But we are not causing any more regressions. I may consider that as a qemu-user issue for this CPU. And it could be fixed on the qemu-user side if it really helps people.
> 
> Maybe I am demanding too much about qemu-user. What do you think?

There is additional step:
The linux cpu vm_version also need to parse the /proc/cpuinfo and add that to the JVM cpu string.
Right now only rv64 and aarch64 opens that file AFIACT.
And in qemu-user the only JVM supported platforms adding qemu to cpuinfo is s390 and rv64.

I'll ask qemu folks and get a feel for if I can upstream some changes addressing this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2791764329

From tschatzl at openjdk.org  Thu Apr 10 07:26:28 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 10 Apr 2025 07:26:28 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v31]
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 45 commits:

 - * fixes after merge related to 32 bit x86 removal
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review: revising young gen length
   * robcasloz review: various minor refactorings
 - Do not unnecessarily pass around tmp2 in x86
 - Refine needs_liveness_data
 - Reorder includes
 - * missing file from merge
 - 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 35 more: https://git.openjdk.org/jdk/compare/45b7c748...39aa903f

-------------

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=30
  Stats: 7118 lines in 110 files changed: 2586 ins; 3598 del; 934 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  Thu Apr 10 07:28:31 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 10 Apr 2025 07:28:31 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 9 Apr 2025 22:24:10 GMT, Martin Doerr  wrote:

> This PR needs an update for x86 platforms when merging: g1BarrierSetAssembler_x86.cpp:117:6: error: 'class MacroAssembler' has no member named 'get_thread'

I fixed this for now, but it will be broken again in just a bit with Aleksey's ongoing removal of x86 32 bit platform efforts.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2791807489

From ihse at openjdk.org  Thu Apr 10 07:34:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 07:34:37 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: 
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
 
Message-ID: 

On Wed, 9 Apr 2025 21:26:15 GMT, Justin Lu  wrote:

>> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties line 22:
>> 
>>> 20: # Peter Smolik
>>> 21: Cp1250 WINDOWS-1250 0x00FF
>>> 22: # Patch attributed to havardw at underdusken.no (H?vard Wigtil)
>> 
>> This does not seem to have been a correct conversion.
>
> Right, that `?` looks to have been incorrectly converted during the ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion as this change is from some time ago.)
> 
> Since the change occurs in a comment (thankfully), it should be harmless and the next upstream update of this file would overwrite this incorrect change. However, this file does not seem to be updated that often, so I can also file an issue to correct this if you would prefer that.

You don't have to do that, I'm working on an omnibus UTF-8 fixing PR right now, where I will include a fix for this as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036695622

From ihse at openjdk.org  Thu Apr 10 07:34:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 07:34:37 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: 
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
 
 
Message-ID: 

On Thu, 10 Apr 2025 07:31:37 GMT, Magnus Ihse Bursie  wrote:

>> Right, that `?` looks to have been incorrectly converted during the ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion as this change is from some time ago.)
>> 
>> Since the change occurs in a comment (thankfully), it should be harmless and the next upstream update of this file would overwrite this incorrect change. However, this file does not seem to be updated that often, so I can also file an issue to correct this if you would prefer that.
>
> You don't have to do that, I'm working on an omnibus UTF-8 fixing PR right now, where I will include a fix for this as well.

If anything, I might be a bit worried that there are more incorrect conversions stemming from this PR, that my automated tools and manual scanning has not revealed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036696723

From kbarrett at openjdk.org  Thu Apr 10 07:51:35 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 10 Apr 2025 07:51:35 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 9 Apr 2025 23:12:00 GMT, Brent Christian  wrote:

>> Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead to intermittent test failures ([JDK-8298783](https://bugs.openjdk.org/browse/JDK-8298783)  is a recent example).
>> 
>> A better mechanism already exists in the private `Reference.waitForReferenceProcessing()` method. This PR makes `waitForReferenceProcessing()` available to tests via the `WhiteBox` and `ForceGC` test libraries.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflection improvements

I made enough detailed suggestions that I decided to offer up what I think the
end result might look like.  I've done some minimal testing of this.

  private Method waitForReferenceProcessingMethod = null;

  private Method getWaitForReferenceProcessingMethod() {
    Method wfrp = waitForReferenceProcessingMethod;
    if (wfrp == null) {
      try {
        wfrp = Reference.class.getDeclaredMethod("waitForReferenceProcessing");
      } catch (NoSuchMethodException e) {
        throw new RuntimeException("Missing Reference::waitForReferenceProcessing");
      }
      try {
        wfrp.setAccessible(true);
      } catch (InaccessibleObjectException e) {
        throw new RuntimeException("Need to add @modules java.base/java.lang.ref:open to test?", e);
      }
      assert wfrp.getReturnType() == Boolean.class;
      assert wfrp.getParameterCount() == 0;
      Class[] ev = wfrp.getExceptionTypes();
      assert ev.length == 1;
      assert ev[0] == InterruptedException.class;
      waitForReferenceProcessingMethod = wfrp;
    }
    return wfrp;
  }

  public boolean waitForReferenceProcessing() throws InterruptedException {
    Method wfrp = getWaitForReferenceProcessingMethod();
    try {
      Boolean result = (Boolean) wfrp.invoke(null);
      return result.booleanValue();
    } catch (IllegalAccessException e) {
      throw new RuntimeException(e);
    } catch (InvocationTargetException e) {
      Throwable cause = e.getCause();
      if (cause instanceof InterruptedException) {
        throw (InterruptedException) cause;
      } else if (cause instanceof RuntimeException) {
        throw (RuntimeException) cause;
      } else {
        throw (Error) cause;
      }
    }
  }

test/lib/jdk/test/whitebox/WhiteBox.java line 570:

> 568:    * This method should usually be called after a call to WhiteBox.fullGC().
> 569:    */
> 570:   public static void waitForReferenceProcessing() {

WhiteBox functions are nearly all ordinary member functions, not static.

test/lib/jdk/test/whitebox/WhiteBox.java line 570:

> 568:    * This method should usually be called after a call to WhiteBox.fullGC().
> 569:    */
> 570:   public static void waitForReferenceProcessing() {

Reference::waitForReferenceProcessing throws InterruptedException.  Probably this should be similarly
declared.

test/lib/jdk/test/whitebox/WhiteBox.java line 570:

> 568:    * This method should usually be called after a call to WhiteBox.fullGC().
> 569:    */
> 570:   public static void waitForReferenceProcessing() {

Reference::waitForReferenceProcessing returns boolean.  This should too.

test/lib/jdk/test/whitebox/WhiteBox.java line 572:

> 570:   public static void waitForReferenceProcessing() {
> 571:     try {
> 572:       Method wfrp = Reference.class.getDeclaredMethod("waitForReferenceProcessing");

Why was the caching of the method removed in the latest commit?

It seems like it might be cleaner to split this into a helper that gets the Method object, with a catch clause
for NoSuchMethodException.  Such a helper would also be a place to verify/assert various properties of
the found method, such as empty parameter list, return type is boolean, one declared exception type
(InterruptedException), all of which can then be assumed by the invocation.

test/lib/jdk/test/whitebox/WhiteBox.java line 574:

> 572:       Method wfrp = Reference.class.getDeclaredMethod("waitForReferenceProcessing");
> 573:       wfrp.setAccessible(true);
> 574:       wfrp.invoke(null, new Object[0]);

Don't need an empty argument vector. Sufficient is `wfrp.invoke(null);`.  I found the documentation
a bit confusing, as it says "the supplied args array may be ... or null."

test/lib/jdk/test/whitebox/WhiteBox.java line 577:

> 575:     } catch (IllegalAccessException iae) {
> 576:       throw new RuntimeException("Need to add @modules java.base/java.lang.ref:open?",
> 577:               iae);

This isn't a useful message, as we won't get here in this case.  Instead of `invoke` failing with this exception,
the earlier `setAccessible` will have failed with `InaccessibleObjectException`.

test/lib/jdk/test/whitebox/WhiteBox.java line 578:

> 576:       throw new RuntimeException("Need to add @modules java.base/java.lang.ref:open?",
> 577:               iae);
> 578:     } catch (NoSuchMethodException | InvocationTargetException e) {

I think for InvocationTargetException the appropriate thing to do is to rethrow the cause, which will
require dispatching on its dynamic type in order to cast to an appropriate static type.  The only checked
exception is InterruptedException.  But it could also be RuntimeException or Error.

-------------

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24527#pullrequestreview-2755384786
PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2036541359
PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2036542867
PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2036554417
PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2036536961
PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2036549322
PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2036707567
PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2036573588

From mbaesken at openjdk.org  Thu Apr 10 08:08:46 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 10 Apr 2025 08:08:46 GMT
Subject: RFR: 8354189: Remove JLI_ReportErrorMessageSys on Windows
Message-ID: 

JLI_ReportErrorMessageSys is not used any more on Windows, so we can remove it and make it UNIX-only (there a still a few remaining usages).

-------------

Commit messages:
 - JDK-8354189

Changes: https://git.openjdk.org/jdk/pull/24563/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24563&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354189
  Stats: 77 lines in 3 files changed: 4 ins; 73 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24563.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24563/head:pull/24563

PR: https://git.openjdk.org/jdk/pull/24563

From eirbjo at openjdk.org  Thu Apr 10 08:10:42 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 10 Apr 2025 08:10:42 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: 
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
 
 
 
Message-ID: <6c6DqyCqyPonBZgUU8BpYJR3JQvMXjWm9ulq4SN25Do=.77775825-716d-4908-ae24-c4cf1ead78a5@github.com>

On Thu, 10 Apr 2025 07:32:18 GMT, Magnus Ihse Bursie  wrote:

>> You don't have to do that, I'm working on an omnibus UTF-8 fixing PR right now, where I will include a fix for this as well.
>
> If anything, I might be a bit worried that there are more incorrect conversions stemming from this PR, that my automated tools and manual scanning has not revealed.

Some observations: 

1: This PR seems to have been abondoned, so perhaps this discussion belongs in #15694 ?

2: The `?` (Unicode 'Latin small letter a with ring above' U+00E5) was correctly encoded as 0xEF in ISO-8859-1 previous to this change.

3: The conversion changed this `0xEF` to the three-byte sequence `ef bf bd`

4: This is as-if the file was incorrctly decoded using UTF-8, then encoded using UTF-8:


byte[] origBytes = "?".getBytes(StandardCharsets.ISO_8859_1);
String decoded = new String(origBytes, StandardCharsets.UTF_8);
byte[] encoded = decoded.getBytes(StandardCharsets.UTF_8);
String hex = HexFormat.of().formatHex(encoded);
assertEquals("efbfbd", hex);
``` 

Like @magicus I'm worried that similar incorrect decoding could have been introduced by the same script in other files.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036767319

From shade at openjdk.org  Thu Apr 10 08:12:36 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Apr 2025 08:12:36 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 2 Apr 2025 18:33:16 GMT, Kim Barrett  wrote:

>> Please review this change which adds a native method providing the
>> implementation of Reference::get.  Referece::get is an intrinsic candidate, so
>> this native method implementation is only used when the intrinsic is not.
>> 
>> Currently there is intrinsic support by the interpreter, C1, C2, and graal,
>> which are always used.  With this change we can later remove all the
>> per-platform interpreter intrinsic implementations, and might also remove the
>> C1 intrinsic implementation.
>> 
>> Testing:
>> (1) mach5 tier1-6 normal (so using all the existing intrinsics).
>> (2) mach5 tier1-6 with interpreter and C1 Reference::get intrinsics disabled.
>
> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - remove timeout by using waitForReferenceProcessing
>  - make ill-timed gc in non-concurrent case less likely
>  - fix test package use

src/java.base/share/classes/java/lang/ref/Reference.java line 357:

> 355:     @IntrinsicCandidate
> 356:     public T get() {
> 357:         return get0();

I am looking at this now and wondering how current intrinsics matchers work in case of virtual calls. 

For example, when type information/profile tells us the receiver is generic `Reference`, but in reality it is a `PhantomReference` subclass, would the call to `PhantomReference.get()` match accidentally to `Reference.get` intrinsic, and thus enter Access API wit `ON_WEAK_REF`? Looks pre-existing, and I would have expected native code to assert, but I also think at least C2 intrinsics do not check the reference type.

It seems both `clear` and `refersTo` side-step all this by: a) not intrinsifying the virtual methods; b) doing `AS_NO_KEEPALIVE` -- so they are not as exposed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2036768100

From alanb at openjdk.org  Thu Apr 10 08:34:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Apr 2025 08:34:48 GMT
Subject: RFR: 8351740: Clean up some code around initialization of encoding
 properties [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 7 Apr 2025 23:43:29 GMT, Stuart Marks  wrote:

>> Some of the code that creates various encoding properties at JVM initialization time, such as file.encoding and native.encoding, could use some cleaning up. Cleanup is fairly minimal and should be mostly behavior-preserving. Changes include the following:
>> 
>> * In the java_props.h and java_props_md.c files, add documentation and asserts that the sprops.encoding and sprops.sun_jnu_encoding members are always set to non-NULL by the platform-specific code.
>> 
>> * In SystemProps.java, remove a null check that is now extraneous based on the above assertion.
>> 
>> * In SystemProps.java, rearrange logic (with no behavior change) around handling of the "COMPAT" value for the file.encoding property.
>> 
>> * In SystemProps.Raw, rename the platform properties array index from _file_encoding_NDX to _native_encoding_NDX.
>> 
>> * In SystemProps.Raw.cmdProperties(), adjust the HashMap size computation. This should actually avoid resizing of the HashMap (unlike the earlier code).
>> 
>> * Adjust various comments in several places for clarity and correctness.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment from file.encoding to native.encoding

Renaming the index is fine, the comments/asserts look okay, I assume you've bump the copyright headers before integrating.

src/java.base/share/classes/jdk/internal/util/SystemProps.java line 79:

> 77:         // Platform defined encodings cannot be overridden on the command line
> 78:         put(props, "sun.jnu.encoding", raw.propDefault(Raw._sun_jnu_encoding_NDX));
> 79:         var nativeEncoding = raw.propDefault(Raw._native_encoding_NDX);

I'd prefer not see "var" here, only because it's not immediately clear that nativeEncoding is a String.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24463#pullrequestreview-2755828614
PR Review Comment: https://git.openjdk.org/jdk/pull/24463#discussion_r2036814492

From shade at openjdk.org  Thu Apr 10 08:36:33 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Apr 2025 08:36:33 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: 
References: 
 
 
 
Message-ID: <03K6ui5yP3iy8HS_C4nurnsrbOymrm_962YA0-U92IM=.0f83b0ac-5895-4e1a-bb22-0006bd5dd888@github.com>

On Thu, 10 Apr 2025 07:25:47 GMT, Thomas Schatzl  wrote:

> I fixed this for now, but it will be broken again in just a bit with Aleksey's ongoing removal of x86 32 bit platform efforts.

I think all x86 cleanups related to GC and adjacent code have landed in mainline now. So I expect no more major conflicts with this PR :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2791985351

From ihse at openjdk.org  Thu Apr 10 08:38:38 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 08:38:38 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <6c6DqyCqyPonBZgUU8BpYJR3JQvMXjWm9ulq4SN25Do=.77775825-716d-4908-ae24-c4cf1ead78a5@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
 
 
 
 <6c6DqyCqyPonBZgUU8BpYJR3JQvMXjWm9ulq4SN25Do=.77775825-716d-4908-ae24-c4cf1ead78a5@github.com>
Message-ID: 

On Thu, 10 Apr 2025 08:08:02 GMT, Eirik Bj?rsn?s  wrote:

>> If anything, I might be a bit worried that there are more incorrect conversions stemming from this PR, that my automated tools and manual scanning has not revealed.
>
> Some observations: 
> 
> 1: This PR seems to have been abondoned, so perhaps this discussion belongs in #15694 ?
> 
> 2: The `?` (Unicode 'Latin small letter a with ring above' U+00E5) was correctly encoded as 0xEF in ISO-8859-1 previous to this change.
> 
> 3: The conversion changed this `0xEF` to the three-byte sequence `ef bf bd`
> 
> 4: This is as-if the file was incorrctly decoded using UTF-8, then encoded using UTF-8:
> 
> 
> byte[] origBytes = "?".getBytes(StandardCharsets.ISO_8859_1);
> String decoded = new String(origBytes, StandardCharsets.UTF_8);
> byte[] encoded = decoded.getBytes(StandardCharsets.UTF_8);
> String hex = HexFormat.of().formatHex(encoded);
> assertEquals("efbfbd", hex);
> ``` 
> 
> Like @magicus I'm worried that similar incorrect decoding could have been introduced by the same script in other files.

> This PR seems to have been abondoned, so perhaps this discussion belongs in https://github.com/openjdk/jdk/pull/15694 ?

Oh, I didn't notice this was supplanted by another PR. It might be better to continue there, yes. Even if closed PRs seldom are the best places to conduct discussions, I think it might be a good idea to scrutinize all files modified by this script.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036820765

From ihse at openjdk.org  Thu Apr 10 08:41:45 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 08:41:45 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu  wrote:

>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>> 
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>> 
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>> 
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>> 
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace InputStreamReader with BufferedReader

Continuing the discussion that was started at a predecessor to this PR, https://github.com/openjdk/jdk/pull/12726#discussion_r2035582242. At least one incorrect conversion has been found in this PR. It might be worthwhile to double- and triple-check all the other conversions as well.

As part of https://bugs.openjdk.org/browse/JDK-8301971 I am trying various ways of detecting files without UTF-8 encoding, but it is still a bit of hit and miss, since there are no surefire way of telling which encoding a file has, only heuristics. So finding and following up potential sources of error is important.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2791991649
PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2791997157

From sgehwolf at openjdk.org  Thu Apr 10 08:45:32 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 10 Apr 2025 08:45:32 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493
In-Reply-To: 
References: 
 <9QVEBGTFqMGaocyisN_zUY9mqQtC3mnJoazB0TH0yqU=.6035d751-84b5-4aa3-baf5-e2d02f692565@github.com>
 <_mC3xJvbf0K_Bb4ywZIMUzDFiUzs70vIZz48z43R5-k=.3c8e049b-a869-4cfa-9623-c30ffea6c549@github.com>
 
Message-ID: 

On Fri, 4 Apr 2025 07:55:20 GMT, Alan Bateman  wrote:

>>> Part of me is concerned that the hidden option is a bit of an attractive nuisance. What would you think about just having a fixed list in a properties file in the repo, thus a resource in the jlink module. This would avoid the list in JRTArchive too. It wouldn't rule out introducing something more in the future.
>> 
>> I'm not entirely sure what you are suggesting. Is it keeping a list of "upgradeable" files in a properties file. Files listed in that properties file aren't checked for hash sums (i.e. even if it's not modified)? That is, the explicit opt-in is not needed? Fine by me, but it's a weaker check. If we don't need the explicit opt-in, the patch becomes simpler as well.
>> 
>>> Right now the only examples we have are in java.base. In time it might be that some other modules might need something.
>> 
>> Sure. I've considered that. The `java.base` specific check can go away and it should work for any module as long as we have a list of what's considered an upgradable file (wherever it comes from).
>>  
>>> I've like to know more about cacerts. Are the distros swapping this to a link after the run-time image is created or is it that the sym link is there from the startup and the hashing has followed the link?
>> 
>> Yes, that's one case. For example Fedora/RHEL distros have a `ca-certificates` package which also provides a `cacerts` file consumable from the JDK (`/etc/pki/java/cacerts`). This can be a build-time option, or replaced  with a symlink after the JDK has been built.
>> 
>> Another use case is amending the cacerts store. For example with an enterprise internal CA, in a container. It's really not different to `tzdb.dat`. That too, can be a symlink to a system package or get updated with an external tool after a build.
>> 
>> The option of not following symlinks, isn't an option, though, as certain distro packaging standards require one to install, say man pages - in a specific directory. To keep the JDK image whole, that is usually fixed by placing a symlink back in the JDK image directory.
>
>> I'm not entirely sure what you are suggesting. Is it keeping a list of "upgradeable" files in a properties file. Files listed in that properties file aren't checked for hash sums (i.e. even if it's not modified)? That is, the explicit opt-in is not needed? Fine by me, but it's a weaker check. If we don't need the explicit opt-in, the patch becomes simpler as well.
> 
> Yes, I think keep simple. We always want to allow tzdb.dat be upgraded by the TZ updater tool. I think treating cacerts the same way is okay. As you note, it has to be kept up to date too. I was thinking keytool import and wasn't sure if the Linux distros configure with `-with-cacerts-file` or did something else. Thanks for the clarification on this point.
> 
> Starting with a simple list of two files won't preclude us from re-visiting it again in the future.

@AlanBateman Any more thoughts on this? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2792010497

From eirbjo at openjdk.org  Thu Apr 10 08:48:37 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 10 Apr 2025 08:48:37 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: 
References: 
 
Message-ID: <0q0gTsqIsYtmzAfNYbBXksUXKdZh2uzQ9yvSETKAP88=.137372e6-d63e-4539-b196-4bd9ef1ddd16@github.com>

On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu  wrote:

>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>> 
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>> 
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>> 
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>> 
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace InputStreamReader with BufferedReader

FWIW, I checked out the revision of the commit previous to this change and found the following:


% git checkout b55e418a077791b39992042411cde97f68dc39fe^ 
% find src -name "*.properties" | xargs file | grep -v ASCII
src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties: 
  ISO-8859 text
src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties:
  Unicode text, UTF-8 text, with very long lines (322)


Which indicates that that this is the only non-ASCII, non-UTF-8 property file. So we may be lucky.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2792014164

From alanb at openjdk.org  Thu Apr 10 09:06:32 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Apr 2025 09:06:32 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 9 Apr 2025 16:10:20 GMT, Severin Gehwolf  wrote:

>> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
>> 
>> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
>> 
>> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
>> 2. For those files the hash sum checks are skipped.
>> 
>> **Testing**
>> 
>> - [x] GHA
>> - [x] `jdk/tools/jlink` jtreg tests (also on [GHA](https://github.com/jerboaa/jdk/actions/runs/14308729271))
>> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use *.conf for upgrade files

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24388#pullrequestreview-2755918801

From alanb at openjdk.org  Thu Apr 10 09:06:33 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Apr 2025 09:06:33 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: <4gu4eWXHBckNDOf135DTWPDAP2pG5cuOl5dniQleJJk=.860242cd-b74a-4b4c-81e0-df05027d77da@github.com>

On Tue, 8 Apr 2025 13:31:10 GMT, Severin Gehwolf  wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/LinkableRuntimeImage.java line 71:
>> 
>>> 69:     private static InputStream getDiffInputStream(String module) throws IOException {
>>> 70:         String resourceName = String.format(DIFF_PATTERN, module);
>>> 71:         return JDK_JLINK_MOD.getResourceAsStream(resourceName);
>> 
>> FYI you can use LinkableRuntimeImage.class.getResourceAsStream here as the resource is in the current module.
>
> It's very odd, but when I attempt this then the resource is not found. It seems to fail on the module name verification. For example: `jlink --help | tail -n2` shows as `disabled` for an enabled linkable runtime image.

Without reproducing, I can't immediately say why Class.getResourceAsStream would fail here. This is a good API for locating resources in the caller's module.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2036873997

From tschatzl at openjdk.org  Thu Apr 10 09:07:39 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 10 Apr 2025 09:07:39 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v32]
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 46 commits:

 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * fixes after merge related to 32 bit x86 removal
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review: revising young gen length
   * robcasloz review: various minor refactorings
 - Do not unnecessarily pass around tmp2 in x86
 - Refine needs_liveness_data
 - Reorder includes
 - * missing file from merge
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - ... and 36 more: https://git.openjdk.org/jdk/compare/f94a4f7a...fcf96a2a

-------------

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=31
  Stats: 7112 lines in 110 files changed: 2592 ins; 3594 del; 926 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 ayang at openjdk.org  Thu Apr 10 09:12:32 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 10 Apr 2025 09:12:32 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 9 Apr 2025 14:32:43 GMT, Thomas Schatzl  wrote:

>> src/hotspot/share/gc/g1/g1ConcurrentRefineSweepTask.cpp line 83:
>> 
>>> 81:         break;
>>> 82:       }
>>> 83:       case G1RemSet::HasRefToOld : break; // Nothing special to do.
>> 
>> Why doesn't call `inc_cards_clean_again` in this case? The card is cleared also. (In fact, I don't get why this needs to a separate case from `NoInteresting`.)
>
> "NoInteresting" means that the card contains no interesting reference at all. "HasRefToOld" means that there has been an interesting reference in the card.
> 
> The distinction between these groups of cards seems interesting to me. E.g. out of X non-clean cards, there were A with a reference to the collection set, B that were already marked as containing a card to the collection, C not having any interesting card any more (transitioned from clean -> dirty -> clean, and cleared by the mutator), D being non-parsable, and E having references to old (and no other references).
> 
> I could add a separate counter for these type of cards too - they can be inferred from the total number of scanned minus the others though.

I see; "clean again" means the existing interesting pointer was overwritten by mutator.

I misinterpret the comment as cards transitioned from dirty to clean. `  size_t _cards_clean_again;          // Dirtied cards that were cleaned.`

To prevent misunderstanding, what do you think of renaming "NoInteresting" to "NoCrossRegion" and "_cards_clean_again" to "_cards_no_cross_region", or sth alike so that the 1:1 mapping is clearer?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2036885633

From sgehwolf at openjdk.org  Thu Apr 10 09:15:42 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 10 Apr 2025 09:15:42 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <5y_3A2YWz__mEiqO4riiVGAh5w53JG_h0FS8Gi7o9-w=.b2844f4a-bdff-4081-880c-c95bf6a6ca3c@github.com>

On Sat, 5 Apr 2025 04:49:03 GMT, Christoph Langer  wrote:

>> Severin Gehwolf 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:
>> 
>>  - Reboot upgradeable files approach
>>  - Revert "8353185: Introduce the concept of upgradeable files in context of JEP 493"
>>    
>>    This reverts commit bfbfbcb8212ed0f9825549b02b4b52e930c379a7.
>>  - Merge branch 'master' into jdk-8353185-upgradable-files-jep493
>>  - 8353185: Introduce the concept of upgradeable files in context of JEP 493
>
> Just a few fly-by findings, no full review.
> 
> I see that you're actively on the upgradeable files. What about #24190? (@AlanBateman, what are your thoughts, how could we progress there?)

@RealCLanger Are you OK with the latest patch (as far as your comments are concerned)?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2792092525

From sgehwolf at openjdk.org  Thu Apr 10 09:15:43 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 10 Apr 2025 09:15:43 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v4]
In-Reply-To: <4gu4eWXHBckNDOf135DTWPDAP2pG5cuOl5dniQleJJk=.860242cd-b74a-4b4c-81e0-df05027d77da@github.com>
References: 
 
 
 
 <4gu4eWXHBckNDOf135DTWPDAP2pG5cuOl5dniQleJJk=.860242cd-b74a-4b4c-81e0-df05027d77da@github.com>
Message-ID: <7IgtqWd24RIfYfO6D2tFKRxQ8BbkELzhReGh9VXG_tQ=.8a405f59-757e-43b9-9dd5-9369451598e5@github.com>

On Thu, 10 Apr 2025 09:03:36 GMT, Alan Bateman  wrote:

>> It's very odd, but when I attempt this then the resource is not found. It seems to fail on the module name verification. For example: `jlink --help | tail -n2` shows as `disabled` for an enabled linkable runtime image.
>
> Without reproducing, I can't immediately say why Class.getResourceAsStream would fail here. This is a good API for locating resources in the caller's module.

I'll try to find a reproducer outside this PR and will let you know if I find anything.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2036887632

From forax at univ-mlv.fr  Thu Apr 10 09:18:29 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 10 Apr 2025 11:18:29 +0200 (CEST)
Subject: java.lang.String hashCode and @Stable ?
Message-ID: <500256835.218906672.1744276709174.JavaMail.zimbra@univ-eiffel.fr>

Question,
why String.hash and String.hashIsZero are not declared @Stable ?

regards,
R?mi

From duke at openjdk.org  Thu Apr 10 09:35:28 2025
From: duke at openjdk.org (Nicole Xu)
Date: Thu, 10 Apr 2025 09:35:28 GMT
Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 27 Feb 2025 03:22:27 GMT, Nicole Xu  wrote:

> Would it be possible to configure the build of the microbenchmarks to not pass `-Werror`, so they don't break when sunapi diagnostics are emitted?
> 
> > Note that even it will raise "proprietary API" warnings after this patch, it is acceptable because the relevant APIs are bound for removal for the integrity of the platform.
> 
> It will not raise those diagnostics today, because they don't work for this compilation due to [JDK-8349846](https://bugs.openjdk.org/browse/JDK-8349846). If that issue is fixed again it would break the build of these benchmarks, e.g. with [1ab1c1d](https://github.com/openjdk/jdk/commit/1ab1c1d53b86228be85aac96fa5d69db39ac6317) backed out and with this change it would fail with:
> 
> ```
> test/micro/org/openjdk/bench/sun/misc/UnsafeOps.java:27: warning: Unsafe is internal proprietary API and may be removed in a future release
> import sun.misc.Unsafe;
>                ^
> ...
> error: warnings found and -Werror specified
> ```

I saw the recent patch [`7aeaa3c`](https://github.com/openjdk/jdk/commit/7aeaa3c21c1420191fe8ff59e4cf99eae830754d), which introduced the `--disable-java-warnings-as-errors` configure option.

I tried to execute the test compilation with this option offline, and the error you mentioned became warnings. Would this address the issue you raised? @cushon

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2792144752

From ihse at openjdk.org  Thu Apr 10 09:45:56 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 09:45:56 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu  wrote:

>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>> 
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>> 
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>> 
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>> 
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace InputStreamReader with BufferedReader

Thanks for checking!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2792170460

From vklang at openjdk.org  Thu Apr 10 09:49:01 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 10 Apr 2025 09:49:01 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v52]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 06:34:24 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 307 commits:
> 
>  - Fix typo
>  - Merge branch 'master' into implement-jep502
>  - Fix typo in return type
>  - Change double to int
>  - Fix typo
>  - Update examples
>  - Remove parantheses
>  - Only use partial functions
>  - Fix typo
>  - Add note an partial and total functions
>  - ... and 297 more: https://git.openjdk.org/jdk/compare/250eb743...9c7b48b7

src/java.base/share/classes/java/lang/StableValue.java line 90:

> 88:  * If {@code getLogger()} is called from several threads, several instances of
> 89:  * {@code Logger} might be created. However, the content can only be set at most once
> 90:  * meaning one "winner" is picked among the many loggers.

Suggestion:

 * meaning that the first writer wins.

src/java.base/share/classes/java/lang/StableValue.java line 92:

> 90:  * meaning one "winner" is picked among the many loggers.
> 91:  * 

> 92:  * To guarantee that, even under races, only one instance of {@code Logger} is ever

Suggestion:

 * In order to guarantee that, even under races, only one instance of {@code Logger} is ever

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2036961021
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2036962326

From tschatzl at openjdk.org  Thu Apr 10 10:02:40 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 10 Apr 2025 10:02:40 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v33]
In-Reply-To: 
References: 
Message-ID: <5FzYDFpFOksmAGM5RV0gGk2eDAdinlDCGo8_37eUeEA=.5f96c37e-7b10-41b4-a607-fc7a665abd67@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 two additional commits since the last revision:

 - * indentation fix
 - * remove support for 32 bit x86 in the barrier generation code, following latest changes from @shade

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/fcf96a2a..068d2a37

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=31-32

  Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 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  Thu Apr 10 10:02:41 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 10 Apr 2025 10:02:41 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: <03K6ui5yP3iy8HS_C4nurnsrbOymrm_962YA0-U92IM=.0f83b0ac-5895-4e1a-bb22-0006bd5dd888@github.com>
References: 
 
 
 
 <03K6ui5yP3iy8HS_C4nurnsrbOymrm_962YA0-U92IM=.0f83b0ac-5895-4e1a-bb22-0006bd5dd888@github.com>
Message-ID: 

On Thu, 10 Apr 2025 08:34:00 GMT, Aleksey Shipilev  wrote:

> > I fixed this for now, but it will be broken again in just a bit with Aleksey's ongoing removal of x86 32 bit platform efforts.
> 
> I think all x86 cleanups related to GC and adjacent code have landed in mainline now. So I expect no more major conflicts with this PR :)

Thanks. :)

@TheRealMDoerr: should be fixed now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2792213039

From ihse at openjdk.org  Thu Apr 10 10:18:13 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 10:18:13 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie  wrote:

> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
> 
> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
> 
> Methodology used: 
> 
> I have run four different tools for using different heuristics for determining the encoding of a file:
> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
> * enca (targeted towards obscure code pages)
> * libmagic / `file  --mime-encoding`
> 
> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
> 
> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
> * All files where at least one tool claimed it to be UTF-8
> * All files where at least one tool claimed it to be *not* UTF-8
> 
> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
> 
> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure binary files, but without any telling exten...

src/hotspot/cpu/x86/macroAssembler_x86_sha.cpp line 497:

> 495: /*
> 496:   The algorithm below is based on Intel publication:
> 497:   "Fast SHA-256 Implementations on Intel(R) Architecture Processors" by Jim Guilford, Kirk Yap and Vinodh Gopal.

Note: There is of course a unicode `?` symbol, which is what it was originally before it was botched here, but I found no reason to keep this, and in the spirit of JDK-8354213, I thought it better to use pure ASCII here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2037012318

From ihse at openjdk.org  Thu Apr 10 10:18:13 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 10:18:13 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
Message-ID: 

I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 

BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.

Methodology used: 

I have run four different tools for using different heuristics for determining the encoding of a file:
* chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
* uchardet (a modern version by freedesktop, used by e.g. Firefox)
* enca (targeted towards obscure code pages)
* libmagic / `file  --mime-encoding`

They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
* `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`

>From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
* All files where at least one tool claimed it to be UTF-8
* All files where at least one tool claimed it to be *not* UTF-8

For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.

For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure binary files, but without any telling extensions (most of these are in tests). The BOM files were only pointed out by chardetect; I did run an additional search for UTF-8 BOM markers over the code base to make sure I did not miss any others (since chardetect apart from this did a not-so-perfect job).

The files included in this PR are what I actually found that had encoding errors or issues.

-------------

Commit messages:
 - Remove UTF-8 BOM (byte-order mark) which is discouraged by the Unicode Consortium
 - Fix incorrect encoding

Changes: https://git.openjdk.org/jdk/pull/24566/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24566&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354266
  Stats: 32 lines in 13 files changed: 0 ins; 2 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/24566.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24566/head:pull/24566

PR: https://git.openjdk.org/jdk/pull/24566

From ihse at openjdk.org  Thu Apr 10 10:23:56 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 10:23:56 GMT
Subject: RFR: 8354273: Restore even more pointless unicode characters to ASCII
Message-ID: 

As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213), I found some additional places where unicode characters are unnecessarily used instead of pure ASCII.

-------------

Commit messages:
 - 8354273: Restore even more pointless unicode characters to ASCII

Changes: https://git.openjdk.org/jdk/pull/24567/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24567&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354273
  Stats: 9 lines in 6 files changed: 0 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/24567.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24567/head:pull/24567

PR: https://git.openjdk.org/jdk/pull/24567

From pminborg at openjdk.org  Thu Apr 10 10:26:36 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 10 Apr 2025 10:26:36 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v53]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Improve docs as per comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/9c7b48b7..6a6dd4b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=52
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=51-52

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From ihse at openjdk.org  Thu Apr 10 10:36:31 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 10:36:31 GMT
Subject: RFR: 8354273: Restore even more pointless unicode characters to
 ASCII [v2]
In-Reply-To: 
References: 
Message-ID: 

> As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213), I found some additional places where unicode characters are unnecessarily used instead of pure ASCII.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Remove incorrectly copied "?anchor"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24567/files
  - new: https://git.openjdk.org/jdk/pull/24567/files/d9527eb9..876708c2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24567&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24567&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24567.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24567/head:pull/24567

PR: https://git.openjdk.org/jdk/pull/24567

From ihse at openjdk.org  Thu Apr 10 10:39:32 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 10:39:32 GMT
Subject: RFR: 8354273: Restore even more pointless unicode characters to
 ASCII [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 10:36:31 GMT, Magnus Ihse Bursie  wrote:

>> As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213), I found some additional places where unicode characters are unnecessarily used instead of pure ASCII.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove incorrectly copied "?anchor"

src/java.xml/share/legal/xmlxsd.md line 29:

> 27:     https://www.w3.org/copyright/software-license-2023/"
> 28: 
> 29: Disclaimers ?anchor

This is an incorrectly copied piece of html; compare how the very same license is handled in e.g. `src/java.xml/share/legal/schema10part1.md`. The ? is the non-ascii character that triggered my detection of this, but the entire "anchor" string is incorrect here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24567#discussion_r2037047696

From mli at openjdk.org  Thu Apr 10 10:42:12 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 10 Apr 2025 10:42:12 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L [v3]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> Can you help to review this patch?
> On riscv, CMoveI/L already were implemented, but there are some gap:
> 1. CMoveI/L does not support comparison with float/double, corresponding tests are not turn on either.
> 2. Some optimization of C2 is not turned on, e.g. `Phi -> CMove -> min_max`.
> 3. lack of some corresponding performance tests.
> 
> Also there are some issue with current Zicond:
> 1. UseZicond is turned on automatically by hwprobe, but jmh tests show that it's not always bring benefit, in some situation it even brings regression, the reason is the generated code by Zicond is much larger than branch version, in particular when it's in a loop and unrolled.
> 
> This patch on riscv is to:
> 1. add CMoveI/L comparing float/double, and corresponding tests,
> 2. enable more C2 optimization,
> 3. add more benchmark tests,
> 4. turn off UseZicond by default.
> 
> Thanks!
> 
> ## Performance
> 
> ### MinMax
> test data
> 
> Benchmark | Mode | Cnt | Score - master | Score - master+UseZbb | Score - -master+UseZicond | Score - master+UseZicond+UseZbb | Score - cmovei | Score - cmovei+UseZbb | Score - cmovei+UseZicond | Score - cmovei+UseZicond+UseZbb | Error | Units | Opt (master/cmovei)
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> o.o.b.vm.compiler.IfMinMax.testReductionInt | avgt | 40 | 17152.075 | 17216.592 | 17272.493 | 17296.89 | 17127.844 | 17036.605 | 17299.333 | 17250.566 | 73.179 | ns/op | 1.001
> o.o.b.vm.compiler.IfMinMax.testReductionLong | avgt | 40 | 19770.828 | 19967.578 | 20268.905 | 20166.165 | 20065.552 | 20059.095 | 20161.914 | 20151.295 | 131.428 | ns/op | 0.985
> o.o.b.vm.compiler.IfMinMax.testSingleInt | avgt | 40 | 114.734 | 114.402 | 114.887 | 114.384 | 114.4 | 110.631 | 112.162 | 110.915 | 0.333 | ns/op | 1.003
> o.o.b.vm.compiler.IfMinMax.testSingleLong | avgt | 40 | 121.53 | 121.711 | 120.91 | 121.665 | 121.309 | 120.57 | 118.639 | 119.373 | 0.451 | ns/op | 1.002
> o.o.b.vm.compiler.IfMinMax.testVectorInt | avgt | 40 | 60130.165 | 60062.303 | 61839.776 | 61895.194 | 15887.398 | 15924.502 | 15874.835 | 15667.936 | 101.94 | ns/op | 3.785
> o.o.b.vm.compiler.IfMinMax.testVectorLong | avgt | 40 | 63855.379 | 6309...

Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:

 - test
 - adjust the way enabling Zicond

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24490/files
  - new: https://git.openjdk.org/jdk/pull/24490/files/10f9adb0..bff391d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24490&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24490&range=01-02

  Stats: 11 lines in 3 files changed: 4 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24490/head:pull/24490

PR: https://git.openjdk.org/jdk/pull/24490

From mli at openjdk.org  Thu Apr 10 10:42:12 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 10 Apr 2025 10:42:12 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 9 Apr 2025 06:52:26 GMT, Fei Yang  wrote:

>> This is to not enable Zicond automatically, but user can still turn it on manually if they want to try or make sure it bring benefit on the specific hardware.
>> Currently it's based on bananapi result, so maybe  in the future we should adjust the default value of UseZicond.
>> I'm fine with either default value.
>
> I just witnessed a couple of warnings (`UseZicond is turned off automatically. Turn it on with -XX:+UseZicond explicitly.`) when doing a native build on my P550 SBC which is not equipped with `Zicond` extension. I don't think that is expected? And I agree that it might be better to keep this option disabled by default and let users decide whether to enable it based on their cases. But what I see is that `UseZicond` will be auto-enabled through hwprobe [1] on my BPI-F3. So I am suggesting to not to do that in my previous comment. Make sense?
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp#L228

Fixed.
Also adjust the way enable Zicond as we just discussed.
Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24490#discussion_r2037051448

From mli at openjdk.org  Thu Apr 10 10:50:07 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 10 Apr 2025 10:50:07 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L [v4]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> Can you help to review this patch?
> On riscv, CMoveI/L already were implemented, but there are some gap:
> 1. CMoveI/L does not support comparison with float/double, corresponding tests are not turn on either.
> 2. Some optimization of C2 is not turned on, e.g. `Phi -> CMove -> min_max`.
> 3. lack of some corresponding performance tests.
> 
> Also there are some issue with current Zicond:
> 1. UseZicond is turned on automatically by hwprobe, but jmh tests show that it's not always bring benefit, in some situation it even brings regression, the reason is the generated code by Zicond is much larger than branch version, in particular when it's in a loop and unrolled.
> 
> This patch on riscv is to:
> 1. add CMoveI/L comparing float/double, and corresponding tests,
> 2. enable more C2 optimization,
> 3. add more benchmark tests,
> 4. turn off UseZicond by default.
> 
> Thanks!
> 
> ## Performance
> 
> ### MinMax
> test data
> 
> Benchmark | Mode | Cnt | Score - master | Score - master+UseZbb | Score - -master+UseZicond | Score - master+UseZicond+UseZbb | Score - cmovei | Score - cmovei+UseZbb | Score - cmovei+UseZicond | Score - cmovei+UseZicond+UseZbb | Error | Units | Opt (master/cmovei)
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> o.o.b.vm.compiler.IfMinMax.testReductionInt | avgt | 40 | 17152.075 | 17216.592 | 17272.493 | 17296.89 | 17127.844 | 17036.605 | 17299.333 | 17250.566 | 73.179 | ns/op | 1.001
> o.o.b.vm.compiler.IfMinMax.testReductionLong | avgt | 40 | 19770.828 | 19967.578 | 20268.905 | 20166.165 | 20065.552 | 20059.095 | 20161.914 | 20151.295 | 131.428 | ns/op | 0.985
> o.o.b.vm.compiler.IfMinMax.testSingleInt | avgt | 40 | 114.734 | 114.402 | 114.887 | 114.384 | 114.4 | 110.631 | 112.162 | 110.915 | 0.333 | ns/op | 1.003
> o.o.b.vm.compiler.IfMinMax.testSingleLong | avgt | 40 | 121.53 | 121.711 | 120.91 | 121.665 | 121.309 | 120.57 | 118.639 | 119.373 | 0.451 | ns/op | 1.002
> o.o.b.vm.compiler.IfMinMax.testVectorInt | avgt | 40 | 60130.165 | 60062.303 | 61839.776 | 61895.194 | 15887.398 | 15924.502 | 15874.835 | 15667.936 | 101.94 | ns/op | 3.785
> o.o.b.vm.compiler.IfMinMax.testVectorLong | avgt | 40 | 63855.379 | 6309...

Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - merge master
 - test
 - adjust the way enabling Zicond
 - typo
 - Merge branch 'master' into cmoveil-v1
 - turn off flag Zicond by default
 - remove
 - initial commit

-------------

Changes: https://git.openjdk.org/jdk/pull/24490/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24490&range=03
  Stats: 952 lines in 17 files changed: 911 ins; 10 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/24490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24490/head:pull/24490

PR: https://git.openjdk.org/jdk/pull/24490

From mli at openjdk.org  Thu Apr 10 10:59:54 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 10 Apr 2025 10:59:54 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L [v5]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> Can you help to review this patch?
> On riscv, CMoveI/L already were implemented, but there are some gap:
> 1. CMoveI/L does not support comparison with float/double, corresponding tests are not turn on either.
> 2. Some optimization of C2 is not turned on, e.g. `Phi -> CMove -> min_max`.
> 3. lack of some corresponding performance tests.
> 
> Also there are some issue with current Zicond:
> 1. UseZicond is turned on automatically by hwprobe, but jmh tests show that it's not always bring benefit, in some situation it even brings regression, the reason is the generated code by Zicond is much larger than branch version, in particular when it's in a loop and unrolled.
> 
> This patch on riscv is to:
> 1. add CMoveI/L comparing float/double, and corresponding tests,
> 2. enable more C2 optimization,
> 3. add more benchmark tests,
> 4. turn off UseZicond by default.
> 
> Thanks!
> 
> ## Performance
> 
> ### MinMax
> test data
> 
> Benchmark | Mode | Cnt | Score - master | Score - master+UseZbb | Score - -master+UseZicond | Score - master+UseZicond+UseZbb | Score - cmovei | Score - cmovei+UseZbb | Score - cmovei+UseZicond | Score - cmovei+UseZicond+UseZbb | Error | Units | Opt (master/cmovei)
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> o.o.b.vm.compiler.IfMinMax.testReductionInt | avgt | 40 | 17152.075 | 17216.592 | 17272.493 | 17296.89 | 17127.844 | 17036.605 | 17299.333 | 17250.566 | 73.179 | ns/op | 1.001
> o.o.b.vm.compiler.IfMinMax.testReductionLong | avgt | 40 | 19770.828 | 19967.578 | 20268.905 | 20166.165 | 20065.552 | 20059.095 | 20161.914 | 20151.295 | 131.428 | ns/op | 0.985
> o.o.b.vm.compiler.IfMinMax.testSingleInt | avgt | 40 | 114.734 | 114.402 | 114.887 | 114.384 | 114.4 | 110.631 | 112.162 | 110.915 | 0.333 | ns/op | 1.003
> o.o.b.vm.compiler.IfMinMax.testSingleLong | avgt | 40 | 121.53 | 121.711 | 120.91 | 121.665 | 121.309 | 120.57 | 118.639 | 119.373 | 0.451 | ns/op | 1.002
> o.o.b.vm.compiler.IfMinMax.testVectorInt | avgt | 40 | 60130.165 | 60062.303 | 61839.776 | 61895.194 | 15887.398 | 15924.502 | 15874.835 | 15667.936 | 101.94 | ns/op | 3.785
> o.o.b.vm.compiler.IfMinMax.testVectorLong | avgt | 40 | 63855.379 | 6309...

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  revert

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24490/files
  - new: https://git.openjdk.org/jdk/pull/24490/files/74a93f02..da64a160

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24490&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24490&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24490/head:pull/24490

PR: https://git.openjdk.org/jdk/pull/24490

From tschatzl at openjdk.org  Thu Apr 10 11:01:42 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 10 Apr 2025 11:01:42 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: 
References: 
 
 <8noWoU1cd2y4EjjK3QZGMLacPC9gkrwn5Ns3XbQbppI=.74de0b05-b8da-417f-8096-de98d7a3d815@github.com>
 
Message-ID: 

On Wed, 9 Apr 2025 12:48:10 GMT, Thomas Schatzl  wrote:

>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 101:
>> 
>>> 99: }
>>> 100: 
>>> 101: void G1BarrierSetAssembler::gen_write_ref_array_post_barrier(MacroAssembler* masm, DecoratorSet decorators,
>> 
>> Have you measured the performance impact of inlining this assembly code instead of resorting to a runtime call as done before? Is it worth the maintenance cost (for every platform), risk of introducing bugs, etc.?
>
> I remember significant impact in some microbenchmark. It's also inlined in Parallel GC. I do not consider it a big issue wrt to maintenance - these things never really change, and the method is small and contained.
> I will try to redo numbers.

>From our microbenchmarks (higher numbers are better):

Current code:

Benchmark                                    (size)   Mode  Cnt       Score      Error   Units
ArrayCopyObject.conjoint_micro                   31  thrpt   15  166136.959 ? 5517.157  ops/ms
ArrayCopyObject.conjoint_micro                   63  thrpt   15  108880.108 ? 4331.112  ops/ms
ArrayCopyObject.conjoint_micro                  127  thrpt   15   93159.977 ? 5025.458  ops/ms
ArrayCopyObject.conjoint_micro                 2047  thrpt   15   17234.842 ?  831.344  ops/ms
ArrayCopyObject.conjoint_micro                 4095  thrpt   15    9202.216 ?  292.612  ops/ms
ArrayCopyObject.conjoint_micro                 8191  thrpt   15    3565.705 ?  121.116  ops/ms
ArrayCopyObject.disjoint_micro                   31  thrpt   15  159106.245 ? 5965.576  ops/ms
ArrayCopyObject.disjoint_micro                   63  thrpt   15   95475.658 ? 5415.267  ops/ms
ArrayCopyObject.disjoint_micro                  127  thrpt   15   84249.979 ? 6313.007  ops/ms
ArrayCopyObject.disjoint_micro                 2047  thrpt   15   10682.650 ?  381.832  ops/ms
ArrayCopyObject.disjoint_micro                 4095  thrpt   15    4471.940 ?  216.439  ops/ms
ArrayCopyObject.disjoint_micro                 8191  thrpt   15    1378.296 ?   33.421  ops/ms
ArrayCopy.arrayCopyObject                       N/A   avgt   15      13.880 ?    0.517   ns/op
ArrayCopy.arrayCopyObjectNonConst               N/A   avgt   15      14.844 ?    0.751   ns/op
ArrayCopy.arrayCopyObjectSameArraysBackward     N/A   avgt   15      11.080 ?    0.703   ns/op
ArrayCopy.arrayCopyObjectSameArraysForward      N/A   avgt   15      11.003 ?    0.135   ns/op

Runtime call:

Benchmark                                    (size)   Mode  Cnt      Score       Error   Units
ArrayCopyObject.conjoint_micro                   31  thrpt   15  73100.230 ? 11079.381  ops/ms
ArrayCopyObject.conjoint_micro                   63  thrpt   15  65039.431 ?  1996.832  ops/ms
ArrayCopyObject.conjoint_micro                  127  thrpt   15  58336.711 ?  2260.660  ops/ms
ArrayCopyObject.conjoint_micro                 2047  thrpt   15  17035.419 ?   524.445  ops/ms
ArrayCopyObject.conjoint_micro                 4095  thrpt   15   9207.661 ?   286.526  ops/ms
ArrayCopyObject.conjoint_micro                 8191  thrpt   15   3264.491 ?    73.848  ops/ms
ArrayCopyObject.disjoint_micro                   31  thrpt   15  84587.219 ?  3007.310  ops/ms
ArrayCopyObject.disjoint_micro                   63  thrpt   15  62815.254 ?  1214.310  ops/ms
ArrayCopyObject.disjoint_micro                  127  thrpt   15  58423.470 ?   285.670  ops/ms
ArrayCopyObject.disjoint_micro                 2047  thrpt   15  10720.462 ?   617.173  ops/ms
ArrayCopyObject.disjoint_micro                 4095  thrpt   15   4178.195 ?   178.942  ops/ms
ArrayCopyObject.disjoint_micro                 8191  thrpt   15   1374.268 ?    44.290  ops/ms
ArrayCopy.arrayCopyObject                       N/A   avgt   15     19.667 ?     0.740   ns/op
ArrayCopy.arrayCopyObjectNonConst               N/A   avgt   15     21.243 ?     1.891   ns/op
ArrayCopy.arrayCopyObjectSameArraysBackward     N/A   avgt   15     16.645 ?     0.504   ns/op
ArrayCopy.arrayCopyObjectSameArraysForward      N/A   avgt   15     17.409 ?     0.705   ns/op

Obviously with larger arrays, the impact diminishes, but it's always there. I think the inlined code is worth the effort in this case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2037086410

From mli at openjdk.org  Thu Apr 10 11:12:51 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 10 Apr 2025 11:12:51 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L [v6]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> Can you help to review this patch?
> On riscv, CMoveI/L already were implemented, but there are some gap:
> 1. CMoveI/L does not support comparison with float/double, corresponding tests are not turn on either.
> 2. Some optimization of C2 is not turned on, e.g. `Phi -> CMove -> min_max`.
> 3. lack of some corresponding performance tests.
> 
> Also there are some issue with current Zicond:
> 1. UseZicond is turned on automatically by hwprobe, but jmh tests show that it's not always bring benefit, in some situation it even brings regression, the reason is the generated code by Zicond is much larger than branch version, in particular when it's in a loop and unrolled.
> 
> This patch on riscv is to:
> 1. add CMoveI/L comparing float/double, and corresponding tests,
> 2. enable more C2 optimization,
> 3. add more benchmark tests,
> 4. turn off UseZicond by default.
> 
> Thanks!
> 
> ## Performance
> 
> ### MinMax
> test data
> 
> Benchmark | Mode | Cnt | Score - master | Score - master+UseZbb | Score - -master+UseZicond | Score - master+UseZicond+UseZbb | Score - cmovei | Score - cmovei+UseZbb | Score - cmovei+UseZicond | Score - cmovei+UseZicond+UseZbb | Error | Units | Opt (master/cmovei)
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> o.o.b.vm.compiler.IfMinMax.testReductionInt | avgt | 40 | 17152.075 | 17216.592 | 17272.493 | 17296.89 | 17127.844 | 17036.605 | 17299.333 | 17250.566 | 73.179 | ns/op | 1.001
> o.o.b.vm.compiler.IfMinMax.testReductionLong | avgt | 40 | 19770.828 | 19967.578 | 20268.905 | 20166.165 | 20065.552 | 20059.095 | 20161.914 | 20151.295 | 131.428 | ns/op | 0.985
> o.o.b.vm.compiler.IfMinMax.testSingleInt | avgt | 40 | 114.734 | 114.402 | 114.887 | 114.384 | 114.4 | 110.631 | 112.162 | 110.915 | 0.333 | ns/op | 1.003
> o.o.b.vm.compiler.IfMinMax.testSingleLong | avgt | 40 | 121.53 | 121.711 | 120.91 | 121.665 | 121.309 | 120.57 | 118.639 | 119.373 | 0.451 | ns/op | 1.002
> o.o.b.vm.compiler.IfMinMax.testVectorInt | avgt | 40 | 60130.165 | 60062.303 | 61839.776 | 61895.194 | 15887.398 | 15924.502 | 15874.835 | 15667.936 | 101.94 | ns/op | 3.785
> o.o.b.vm.compiler.IfMinMax.testVectorLong | avgt | 40 | 63855.379 | 6309...

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  enable more IR tests depending enabling CMove

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24490/files
  - new: https://git.openjdk.org/jdk/pull/24490/files/da64a160..53603ec7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24490&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24490&range=04-05

  Stats: 8 lines in 2 files changed: 0 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24490/head:pull/24490

PR: https://git.openjdk.org/jdk/pull/24490

From rcastanedalo at openjdk.org  Thu Apr 10 11:22:36 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 10 Apr 2025 11:22:36 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v30]
In-Reply-To: 
References: 
 
 <8noWoU1cd2y4EjjK3QZGMLacPC9gkrwn5Ns3XbQbppI=.74de0b05-b8da-417f-8096-de98d7a3d815@github.com>
 
 
Message-ID: 

On Thu, 10 Apr 2025 10:58:24 GMT, Thomas Schatzl  wrote:

>> I remember significant impact in some microbenchmark. It's also inlined in Parallel GC. I do not consider it a big issue wrt to maintenance - these things never really change, and the method is small and contained.
>> I will try to redo numbers.
>
> From our microbenchmarks (higher numbers are better):
> 
> Current code:
> 
> Benchmark                                    (size)   Mode  Cnt       Score      Error   Units
> ArrayCopyObject.conjoint_micro                   31  thrpt   15  166136.959 ? 5517.157  ops/ms
> ArrayCopyObject.conjoint_micro                   63  thrpt   15  108880.108 ? 4331.112  ops/ms
> ArrayCopyObject.conjoint_micro                  127  thrpt   15   93159.977 ? 5025.458  ops/ms
> ArrayCopyObject.conjoint_micro                 2047  thrpt   15   17234.842 ?  831.344  ops/ms
> ArrayCopyObject.conjoint_micro                 4095  thrpt   15    9202.216 ?  292.612  ops/ms
> ArrayCopyObject.conjoint_micro                 8191  thrpt   15    3565.705 ?  121.116  ops/ms
> ArrayCopyObject.disjoint_micro                   31  thrpt   15  159106.245 ? 5965.576  ops/ms
> ArrayCopyObject.disjoint_micro                   63  thrpt   15   95475.658 ? 5415.267  ops/ms
> ArrayCopyObject.disjoint_micro                  127  thrpt   15   84249.979 ? 6313.007  ops/ms
> ArrayCopyObject.disjoint_micro                 2047  thrpt   15   10682.650 ?  381.832  ops/ms
> ArrayCopyObject.disjoint_micro                 4095  thrpt   15    4471.940 ?  216.439  ops/ms
> ArrayCopyObject.disjoint_micro                 8191  thrpt   15    1378.296 ?   33.421  ops/ms
> ArrayCopy.arrayCopyObject                       N/A   avgt   15      13.880 ?    0.517   ns/op
> ArrayCopy.arrayCopyObjectNonConst               N/A   avgt   15      14.844 ?    0.751   ns/op
> ArrayCopy.arrayCopyObjectSameArraysBackward     N/A   avgt   15      11.080 ?    0.703   ns/op
> ArrayCopy.arrayCopyObjectSameArraysForward      N/A   avgt   15      11.003 ?    0.135   ns/op
> 
> Runtime call:
> 
> Benchmark                                    (size)   Mode  Cnt      Score       Error   Units
> ArrayCopyObject.conjoint_micro                   31  thrpt   15  73100.230 ? 11079.381  ops/ms
> ArrayCopyObject.conjoint_micro                   63  thrpt   15  65039.431 ?  1996.832  ops/ms
> ArrayCopyObject.conjoint_micro                  127  thrpt   15  58336.711 ?  2260.660  ops/ms
> ArrayCopyObject.conjoint_micro                 2047  thrpt   15  17035.419 ?   524.445  ops/ms
> ArrayCopyObject.conjoint_micro                 4095  thrpt   15   9207.661 ?   286.526  ops/ms
> ArrayCopyObject.conjoint_micro                 8191  thrpt   15   3264.491 ?    73.848  ops/ms
> ArrayCopyObject.disjoint_micro                   31  thrpt   15  84587.219 ?  3007.310  ops/ms
> ArrayCopyObject.disjoint_micro         ...

Fair enough, thanks for the measurements!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2037121277

From rgiulietti at openjdk.org  Thu Apr 10 11:49:30 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 10 Apr 2025 11:49:30 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 10:14:40 GMT, Magnus Ihse Bursie  wrote:

>> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
>> 
>> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
>> 
>> Methodology used: 
>> 
>> I have run four different tools for using different heuristics for determining the encoding of a file:
>> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
>> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
>> * enca (targeted towards obscure code pages)
>> * libmagic / `file  --mime-encoding`
>> 
>> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
>> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
>> 
>> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
>> * All files where at least one tool claimed it to be UTF-8
>> * All files where at least one tool claimed it to be *not* UTF-8
>> 
>> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
>> 
>> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure...
>
> src/hotspot/cpu/x86/macroAssembler_x86_sha.cpp line 497:
> 
>> 495: /*
>> 496:   The algorithm below is based on Intel publication:
>> 497:   "Fast SHA-256 Implementations on Intel(R) Architecture Processors" by Jim Guilford, Kirk Yap and Vinodh Gopal.
> 
> Note: There is of course a unicode `?` symbol, which is what it was originally before it was botched here, but I found no reason to keep this, and in the spirit of JDK-8354213, I thought it better to use pure ASCII here.

I guess the difference at L.1 in the various files is just the BOM?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2037161789

From mli at openjdk.org  Thu Apr 10 12:08:29 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 10 Apr 2025 12:08:29 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L [v7]
In-Reply-To: 
References: 
Message-ID: <317DYBGa3NAUfowhgTFeq8Crezuz-mV9io6nW1IXccc=.d37f6b47-ac06-4234-9162-8aca891630d7@github.com>

> Hi,
> Can you help to review this patch?
> On riscv, CMoveI/L already were implemented, but there are some gap:
> 1. CMoveI/L does not support comparison with float/double, corresponding tests are not turn on either.
> 2. Some optimization of C2 is not turned on, e.g. `Phi -> CMove -> min_max`.
> 3. lack of some corresponding performance tests.
> 
> Also there are some issue with current Zicond:
> 1. UseZicond is turned on automatically by hwprobe, but jmh tests show that it's not always bring benefit, in some situation it even brings regression, the reason is the generated code by Zicond is much larger than branch version, in particular when it's in a loop and unrolled.
> 
> This patch on riscv is to:
> 1. add CMoveI/L comparing float/double, and corresponding tests,
> 2. enable more C2 optimization,
> 3. add more benchmark tests,
> 4. turn off UseZicond by default.
> 
> Thanks!
> 
> ## Performance
> 
> ### MinMax
> test data
> 
> Benchmark | Mode | Cnt | Score - master | Score - master+UseZbb | Score - -master+UseZicond | Score - master+UseZicond+UseZbb | Score - cmovei | Score - cmovei+UseZbb | Score - cmovei+UseZicond | Score - cmovei+UseZicond+UseZbb | Error | Units | Opt (master/cmovei)
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> o.o.b.vm.compiler.IfMinMax.testReductionInt | avgt | 40 | 17152.075 | 17216.592 | 17272.493 | 17296.89 | 17127.844 | 17036.605 | 17299.333 | 17250.566 | 73.179 | ns/op | 1.001
> o.o.b.vm.compiler.IfMinMax.testReductionLong | avgt | 40 | 19770.828 | 19967.578 | 20268.905 | 20166.165 | 20065.552 | 20059.095 | 20161.914 | 20151.295 | 131.428 | ns/op | 0.985
> o.o.b.vm.compiler.IfMinMax.testSingleInt | avgt | 40 | 114.734 | 114.402 | 114.887 | 114.384 | 114.4 | 110.631 | 112.162 | 110.915 | 0.333 | ns/op | 1.003
> o.o.b.vm.compiler.IfMinMax.testSingleLong | avgt | 40 | 121.53 | 121.711 | 120.91 | 121.665 | 121.309 | 120.57 | 118.639 | 119.373 | 0.451 | ns/op | 1.002
> o.o.b.vm.compiler.IfMinMax.testVectorInt | avgt | 40 | 60130.165 | 60062.303 | 61839.776 | 61895.194 | 15887.398 | 15924.502 | 15874.835 | 15667.936 | 101.94 | ns/op | 3.785
> o.o.b.vm.compiler.IfMinMax.testVectorLong | avgt | 40 | 63855.379 | 6309...

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  enable more test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24490/files
  - new: https://git.openjdk.org/jdk/pull/24490/files/53603ec7..7860aba1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24490&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24490&range=05-06

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24490/head:pull/24490

PR: https://git.openjdk.org/jdk/pull/24490

From pminborg at openjdk.org  Thu Apr 10 12:54:52 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 10 Apr 2025 12:54:52 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v51]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 9 Apr 2025 17:25:02 GMT, R?mi Forax  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in return type
>
> Hello,
> I do not know if you know but StableValue.map() does not seems to be optimized correctly.
> 
> Here is the benchmark i use:
> 
> @Warmup(iterations = 5, time = 2, timeUnit = TimeUnit.SECONDS)
> @Measurement(iterations = 5, time = 2, timeUnit = TimeUnit.SECONDS)
> @Fork(value = 1, jvmArgs = { "--enable-preview" })
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @State(Scope.Benchmark)
> public class StableValueBenchmarks {
>   private static final MemoryLayout LAYOUT = MemoryLayout.structLayout(
>       ValueLayout.JAVA_INT.withName("x"),
>       ValueLayout.JAVA_INT.withName("y")
>   );
> 
>   private static final long SIZEOF = LAYOUT.byteSize();
>   private static final long OFFSET_X = LAYOUT.byteOffset(groupElement("x"));
>   private static final long OFFSET_Y = LAYOUT.byteOffset(groupElement("y"));
> 
>   private static final VarHandle VH_X = LAYOUT.arrayElementVarHandle(groupElement("x"))
>       .withInvokeExactBehavior();
>   private static final VarHandle VH_Y = LAYOUT.arrayElementVarHandle(groupElement("y"))
>       .withInvokeExactBehavior();
> 
>   private static final Supplier SV_X = StableValue.supplier(
>       () -> LAYOUT.arrayElementVarHandle(groupElement("x")).withInvokeExactBehavior());
>   private static final Supplier SV_Y = StableValue.supplier(
>       () -> LAYOUT.arrayElementVarHandle(groupElement("y")).withInvokeExactBehavior());
> 
>   private static final Map SMAP = StableValue.map(
>       Set.of("x", "y"),
>       name -> LAYOUT.arrayElementVarHandle(groupElement(name)).withInvokeExactBehavior());
> 
>   private final MemorySegment confined;
>   {
>     var array = new int[512 * (int) SIZEOF / (int) ValueLayout.JAVA_INT.byteSize()];
>     var heap = MemorySegment.ofArray(array);
>     for(var i = 0; i < 512; i++) {
>       heap.set(ValueLayout.JAVA_INT, i * SIZEOF + OFFSET_X, i);
>       heap.set(ValueLayout.JAVA_INT, i * SIZEOF + OFFSET_Y, i);
>     }
>     confined = Arena.ofConfined().allocate(LAYOUT, 512);
>     confined.copyFrom(heap);
>   }
> 
>   @Benchmark
>   public int confinedVarHandleLoop() {
>     var sum = 0;
>     for(var i = 0; i < 512; i++) {
>       var x = (int) VH_X.get(confined, 0L, (long) i);
>       var y = (int) VH_Y.get(confined, 0L, (long) i);
>       sum += x +y;
>     }
>     return sum;
>   }
> 
>   @Benchmark
>   public int confinedStableValueLoop() {
>     var sum = 0;
>     for(var i = 0; i < 512; i++) {
>       var x = (int) SV_X.get().get(confined, 0L, (long) i);
>       var y = (int) SV_Y.get().get(confined, 0L, (long) i);
>       sum += x +...

@forax The same problem can be observed using pure unmodifiable maps so there is a problem elsewhere:


    private static final Map U_MAP = Map.of(
            "x", VH_X,
            "y", VH_Y);
            
...

    @Benchmark
    public int confinedUnmodifiableMapLoop() {
        var sum = 0;
        for(var i = 0; i < 512; i++) {
            var x = (int) U_MAP.get("x").get(confined, 0L, (long) i);
            var y = (int) U_MAP.get("y").get(confined, 0L, (long) i);
            sum += x +y;
        }
        return sum;
    }            
            


I will take a look at it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2792664301

From vklang at openjdk.org  Thu Apr 10 13:02:59 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 10 Apr 2025 13:02:59 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v53]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 10:26:36 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve docs as per comments

src/java.base/share/classes/java/lang/StableValue.java line 93:

> 91:  * 

> 92:  * In order to guarantee that, even under races, only one instance of {@code Logger} is
> 93:  * evee created, the {@linkplain #orElseSet(Supplier) orElseSet()} method can be used

Typo:

Suggestion:

 * ever created, the {@linkplain #orElseSet(Supplier) orElseSet()} method can be used

src/java.base/share/classes/java/lang/StableValue.java line 94:

> 92:  * In order to guarantee that, even under races, only one instance of {@code Logger} is
> 93:  * evee created, the {@linkplain #orElseSet(Supplier) orElseSet()} method can be used
> 94:  * instead, where the content is atomically and lazily computed via a

Suggestion:

 * instead, where the content is lazily computed, and atomically set, via a

src/java.base/share/classes/java/lang/StableValue.java line 120:

> 118:  * evaluates and sets the content; the content is then returned to the client. In other
> 119:  * words, {@code orElseSet()} guarantees that a stable value's content is set
> 120:  * before it is used.

Suggestion:

 * before it is returned.

src/java.base/share/classes/java/lang/StableValue.java line 131:

> 129:  * Stable values provide the foundation for higher-level functional abstractions. A
> 130:  * stable supplier is a supplier that computes a value and then caches it into
> 131:  * a backing stable value storage for later use. A stable supplier is created via the

Suggestion:

 * a backing stable value storage for subsequent use. A stable supplier is created via the

src/java.base/share/classes/java/lang/StableValue.java line 133:

> 131:  * a backing stable value storage for later use. A stable supplier is created via the
> 132:  * {@linkplain StableValue#supplier(Supplier) StableValue.supplier()} factory, by
> 133:  * providing an original {@linkplain Supplier} which is invoked when the stable supplier

Suggestion:

 * providing an underlying {@linkplain Supplier} which is invoked when the stable supplier

src/java.base/share/classes/java/lang/StableValue.java line 169:

> 167:  *     private static final int SIZE = 6;
> 168:  *     private static final IntFunction ORIGINAL_POWER_OF_TWO =
> 169:  *             v -> 1 << v;

Suggestion:

 *         v -> 1 << v;

src/java.base/share/classes/java/lang/StableValue.java line 173:

> 171:  *     private static final IntFunction POWER_OF_TWO =
> 172:  *             // @link substring="intFunction" target="#intFunction(int,IntFunction)" :
> 173:  *             StableValue.intFunction(SIZE, ORIGINAL_POWER_OF_TWO);

Suggestion:

 *         // @link substring="intFunction" target="#intFunction(int,IntFunction)" :
 *         StableValue.intFunction(SIZE, ORIGINAL_POWER_OF_TWO);

src/java.base/share/classes/java/lang/StableValue.java line 180:

> 178:  * }
> 179:  *
> 180:  * int pwr4 = PowerOf2Util.powerOfTwo(4);   // May eventually constant fold to 16 at runtime

Suggestion:

 * int result = PowerOf2Util.powerOfTwo(4);   // May eventually constant fold to 16 at runtime

src/java.base/share/classes/java/lang/StableValue.java line 208:

> 206:  *     private static final Function LOG2 =
> 207:  *             // @link substring="function" target="#function(Set,Function)" :
> 208:  *             StableValue.function(KEYS, ORIGINAL_LOG2);

Suggestion:

 *     private static final Set KEYS =
 *         Set.of(1, 2, 4, 8, 16, 32);
 *     private static final UnaryOperator ORIGINAL_LOG2 =
 *         i -> 31 - Integer.numberOfLeadingZeros(i);
 *
 *     private static final Function LOG2 =
 *         // @link substring="function" target="#function(Set,Function)" :
 *         StableValue.function(KEYS, ORIGINAL_LOG2);

src/java.base/share/classes/java/lang/StableValue.java line 216:

> 214:  * }
> 215:  *
> 216:  * int log16 = Log2Util.log2(16);   // May eventually constant fold to 4 at runtime

Suggestion:

 * int result = Log2Util.log2(16);   // May eventually constant fold to 4 at runtime

src/java.base/share/classes/java/lang/StableValue.java line 240:

> 238:  *     private static final List POWER_OF_TWO =
> 239:  *             // @link substring="list" target="#list(int,IntFunction)" :
> 240:  *             StableValue.list(SIZE, ORIGINAL_POWER_OF_TWO);

Suggestion:

 *             v -> 1 << v;
 *
 *     private static final List POWER_OF_TWO =
 *         // @link substring="list" target="#list(int,IntFunction)" :
 *         StableValue.list(SIZE, ORIGINAL_POWER_OF_TWO);

src/java.base/share/classes/java/lang/StableValue.java line 247:

> 245:  * }
> 246:  *
> 247:  * int pwr4 = PowerOf2Util.powerOfTwo(4);   // May eventually constant fold to 16 at runtime

Suggestion:

 * int result = PowerOf2Util.powerOfTwo(4);   // May eventually constant fold to 16 at runtime

src/java.base/share/classes/java/lang/StableValue.java line 267:

> 265:  *     private static final Map LOG2 =
> 266:  *             // @link substring="map" target="#map(Set,Function)" :
> 267:  *             StableValue.map(CACHED_KEYS, LOG2_ORIGINAL);

Suggestion:

 *         Set.of(1, 2, 4, 8, 16, 32);
 *     private static final UnaryOperator LOG2_ORIGINAL =
 *         i -> 31 - Integer.numberOfLeadingZeros(i);
 *
 *     private static final Map LOG2 =
 *         // @link substring="map" target="#map(Set,Function)" :
 *         StableValue.map(CACHED_KEYS, LOG2_ORIGINAL);

src/java.base/share/classes/java/lang/StableValue.java line 275:

> 273:  * }
> 274:  *
> 275:  * int log16 = Log2Util.log2(16);   // May eventually constant fold to 4 at runtime

Suggestion:

 * int result = Log2Util.log2(16);   // May eventually constant fold to 4 at runtime

src/java.base/share/classes/java/lang/StableValue.java line 318:

> 316:  * 

> 317:  * Here is another example where a more complex dependency graph is created in which
> 318:  * integers in the Fibonacci delta series are lazily computed:

I'd probably reword this to: "Another example, which has a more complex dependency graph, is computing the Fibonacci sequence:"

src/java.base/share/classes/java/lang/StableValue.java line 327:

> 325:  *
> 326:  *     private static final IntFunction FIB =
> 327:  *             StableValue.intFunction(MAX_SIZE_INT, Fibonacci::fib);

Suggestion:

 *         StableValue.intFunction(MAX_SIZE_INT, Fibonacci::fib);

src/java.base/share/classes/java/lang/StableValue.java line 357:

> 355:  *
> 356:  * If there are circular dependencies in a dependency graph, a stable value will
> 357:  * eventually throw an {@linkplain IllegalStateException} upon referencing elements in

Suggestion:

 * eventually throw an {@linkplain IllegalStateException} upon detecting

src/java.base/share/classes/java/lang/StableValue.java line 491:

> 489:      *
> 490:      * {@snippet lang=java:
> 491:      * Value witness = stable.orElseSet(Value::new);

Suggestion:

     * Value v = stable.orElseSet(Value::new);

src/java.base/share/classes/java/lang/StableValue.java line 565:

> 563:      * the returned supplier's {@linkplain Supplier#get() get()} method.
> 564:      * 

> 565:      * The provided {@code original} supplier is guaranteed to be successfully invoked

Personally I prefer "underlying" over "original".

src/java.base/share/classes/java/lang/StableValue.java line 582:

> 580:     static  Supplier supplier(Supplier original) {
> 581:         Objects.requireNonNull(original);
> 582:         return StableSupplier.of(original);

I guess if `original` is a StableSupplier then we could just return that?

src/java.base/share/classes/java/lang/StableValue.java line 614:

> 612:      * @throws IllegalArgumentException if the provided {@code size} is negative.
> 613:      */
> 614:     static  IntFunction intFunction(int size,

Does an intFunction of size 0 make sense?

test/jdk/java/lang/StableValue/StableFunctionTest.java line 25:

> 23: 
> 24: /* @test
> 25:  * @summary Basic tests for StableFunctionTest methods

Suggestion:

 * @summary Basic tests for StableFunction methods

test/jdk/java/lang/StableValue/StableIntFunctionTest.java line 25:

> 23: 
> 24: /* @test
> 25:  * @summary Basic tests for StableIntFunctionTest methods

Suggestion:

 * @summary Basic tests for StableIntFunction methods

test/jdk/java/lang/StableValue/StableListTest.java line 25:

> 23: 
> 24: /* @test
> 25:  * @summary Basic tests for LazyList methods

Suggestion:

 * @summary Basic tests for StableList methods

test/jdk/java/lang/StableValue/StableMapTest.java line 25:

> 23: 
> 24: /* @test
> 25:  * @summary Basic tests for LazyMap methods

Suggestion:

 * @summary Basic tests for StableMap methods

test/jdk/java/lang/StableValue/StableSupplierTest.java line 25:

> 23: 
> 24: /* @test
> 25:  * @summary Basic tests for StableSupplierTest methods

Suggestion:

 * @summary Basic tests for StableSupplier methods

test/jdk/java/lang/StableValue/StableValueFactoriesTest.java line 25:

> 23: 
> 24: /* @test
> 25:  * @summary Basic tests for StableValueFactoriesTest implementations

Suggestion:

 * @summary Basic tests for StableValue factory implementations

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037168882
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037169961
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037172243
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037174262
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037174898
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037177853
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037178275
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037179545
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037180933
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037181796
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037193456
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037194051
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037195527
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037195700
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037202304
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037229765
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037234988
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037250964
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037256596
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037258059
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037261762
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037279107
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037278760
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037278239
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037279632
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037280278
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037282580

From rgiulietti at openjdk.org  Thu Apr 10 13:08:45 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 10 Apr 2025 13:08:45 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v32]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 28 Mar 2025 18:24:49 GMT, fabioromano1  wrote:

>> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed up `BigDecimal.sqrt()` implementation. Here is how I made it.
>> 
>> The main steps of the algorithm are as follows:
>> first argument reduce the value to an integer using the following relations:
>> 
>> x = y * 10 ^ exp
>> sqrt(x) = sqrt(y) * 10^(exp / 2) if exp is even
>> sqrt(x) = sqrt(y*10) * 10^((exp-1)/2) is exp is odd
>> 
>> Then use BigInteger.sqrt() on the reduced value to compute the numerical digits of the desired result.
>> 
>> Finally, scale back to the desired exponent range and perform any adjustment to get the preferred scale in the representation.
>
> fabioromano1 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 36 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patchBigDecimalSqrt
>  - An optimization
>  - Refine documentation
>  - Speed up computation of bitLength()
>  - An optimization
>  - Make digitLengthLower() static
>  - Optimization for integer BigDecimals detection
>  - Optimized integer BigDecimals detection
>  - Added test for scale overflow
>  - Added tests for exact results path
>  - ... and 26 more: https://git.openjdk.org/jdk/compare/b917598c...378569c5

@fabioromano1 Thanks so much for your great work and patience!

-------------

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21301#pullrequestreview-2756665611

From ihse at openjdk.org  Thu Apr 10 13:17:24 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 13:17:24 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 10 Apr 2025 11:46:45 GMT, Raffaello Giulietti  wrote:

> I guess the difference at L.1 in the various files is just the BOM?

Yes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2037357899

From jengebr at amazon.com  Thu Apr 10 13:33:47 2025
From: jengebr at amazon.com (Engebretson, John)
Date: Thu, 10 Apr 2025 13:33:47 +0000
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: 
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 
 <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 
 
 <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
 
 <3f1c69a7ac5946809d2af850d7d59db9@amazon.com>
 
 
Message-ID: 

  Thank you Archie and Chen!
  Chen - I?m prototyping the generic allocator you describe and it?s extremely effective for Objects ? but I?m hamstrung by trying to use generics on primitive byte.  I?m not aware of a way to work around that, and changing the array from byte[] to Byte[] would be a terrible idea, so I think we?re looking at two different allocators.  The template suggested by Archie may help implement that, but ultimately it?ll be multiple classes.
  Archie ? your suggestion generally matches the implementation on the PR, except that the implementation is flexible on the segment size and each instance ?self-tunes? based on inputs.  There are a few hard-coded scaling constants that we could consider tweaking, but my perf tests so far show they?re reasonable in the general case.  Self-managing eliminates guesswork about N and, most importantly, eliminates duplicative copying/allocation after the byte has been recorded.  The benchmark tests a handful of hard-coded sizes and can easily be expanded to handle more, at the expense of longer runtimes.
  I?ll update the PR later today with these new suggestions alongside the current, so we can clearly evaluate pros and cons.
  Thanks!
     John

At the risk of repeating my previous comment, I agree with Chen.

That is to say, there is a separate, more fundamental unsolved problem lurking underneath this discussion, and the two problem "layers" are perhaps better addressed separately.

Once the lower layer problem is properly framed and resolved, it becomes reusable, and wrapping it to solve various higher-layer problems is easy.

An internal class would be a reasonable and conservative way to start. There could even be a suite of such classes, built from templates a la X-Buffer.java.template.

These could be used all over the place (e.g., refactor StringBuilder). For example, I wonder how much the performance of e.g. ArrayList could be improved in scenarios where you are building (or removing elements from) large lists?

Just thinking out loud (apologies)... Define a "segmented array allocator" as an in-memory byte[] array builder that "chunks" the data into individual segments of size at most N.

We can think of the current ByteArrayOutputStream as such a thing with N = 2?? that is, there's only ever one "chunk".

The assertion is that N = 2?? is not the most efficient value. And obviously neither is N = 1.

So somewhere in the middle there is an optimal value for N, which presumably could be discovered via experimentation. It may be different for different architectures.

Another parameter would be: What is the size M ? N of a new chunk? E.g. you could start with M = 16 and then the chunk grows exponentially until it reaches N, at which point you start a new chunk. The optimal value for M could also be performance tested (it may already have been).

Of course, for performance optimization we'd need some distribution of array sizes that models "typical" use, etc.

-Archie

On Wed, Apr 9, 2025 at 6:19?PM Chen Liang > wrote:
Hi John Engebretson,
I still wonder if we can make the byte array allocator a utility to the JDK, at least an internal one. I find that besides replacing BAOS uses, it can also optimize users like InputStream.readNBytes, BufWriterImpl of classfile, and maybe many more usages. Such an internal addition may be accepted to the JDK immediately because it has no compatibility impact and does not need to undergo CSR review.

Chen Liang


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From forax at openjdk.org  Thu Apr 10 13:42:47 2025
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 10 Apr 2025 13:42:47 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v51]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 10 Apr 2025 12:51:43 GMT, Per Minborg  wrote:

>             
> ```
> 
> I will take a look at it.

As i said in another mail to core-lib this morning, it seems that the field storing the hashcode of String is not marked with @Stable. That's may be the issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2793128438

From rriggs at openjdk.org  Thu Apr 10 13:46:39 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 10 Apr 2025 13:46:39 GMT
Subject: RFR: 8351740: Clean up some code around initialization of encoding
 properties [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 7 Apr 2025 23:43:29 GMT, Stuart Marks  wrote:

>> Some of the code that creates various encoding properties at JVM initialization time, such as file.encoding and native.encoding, could use some cleaning up. Cleanup is fairly minimal and should be mostly behavior-preserving. Changes include the following:
>> 
>> * In the java_props.h and java_props_md.c files, add documentation and asserts that the sprops.encoding and sprops.sun_jnu_encoding members are always set to non-NULL by the platform-specific code.
>> 
>> * In SystemProps.java, remove a null check that is now extraneous based on the above assertion.
>> 
>> * In SystemProps.java, rearrange logic (with no behavior change) around handling of the "COMPAT" value for the file.encoding property.
>> 
>> * In SystemProps.Raw, rename the platform properties array index from _file_encoding_NDX to _native_encoding_NDX.
>> 
>> * In SystemProps.Raw.cmdProperties(), adjust the HashMap size computation. This should actually avoid resizing of the HashMap (unlike the earlier code).
>> 
>> * Adjust various comments in several places for clarity and correctness.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment from file.encoding to native.encoding

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24463#pullrequestreview-2756886159

From pminborg at openjdk.org  Thu Apr 10 13:51:15 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 10 Apr 2025 13:51:15 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v53]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 10:26:36 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve docs as per comments

> > ```
> > 
> > I will take a look at it.
> > ```
> 
> As i said in another mail to core-lib this morning, it seems that the field storing the hashcode of String is not marked with @stable. That's may be the issue.

Yes. I can confirm that this is the root cause of the problem:


Benchmark                         Mode  Cnt    Score    Error  Units
Tmp.confinedStableFunctionLoop    avgt    5  153.522 ?  6.707  ns/op
Tmp.confinedStableMapElementLoop  avgt    5  142.780 ?  4.077  ns/op
Tmp.confinedStableMapLoop         avgt    5  157.815 ? 17.250  ns/op
Tmp.confinedStableValueLoop       avgt    5  142.940 ?  2.721  ns/op
Tmp.confinedUnmodifiableMapLoop   avgt    5  142.542 ? 10.049  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2793199126

From pminborg at openjdk.org  Thu Apr 10 13:51:15 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 10 Apr 2025 13:51:15 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v54]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove support function and clean up benchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/6a6dd4b4..70a15815

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=53
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=52-53

  Stats: 157 lines in 2 files changed: 151 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From rgiulietti at openjdk.org  Thu Apr 10 13:56:42 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 10 Apr 2025 13:56:42 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie  wrote:

> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
> 
> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
> 
> Methodology used: 
> 
> I have run four different tools for using different heuristics for determining the encoding of a file:
> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
> * enca (targeted towards obscure code pages)
> * libmagic / `file  --mime-encoding`
> 
> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
> 
> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
> * All files where at least one tool claimed it to be UTF-8
> * All files where at least one tool claimed it to be *not* UTF-8
> 
> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
> 
> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure binary files, but without any telling exten...

I only checked these 13 files to be UTF-8 encoded and without BOM.

-------------

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24566#pullrequestreview-2756936848

From pminborg at openjdk.org  Thu Apr 10 14:10:50 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 10 Apr 2025 14:10:50 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v53]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 10 Apr 2025 12:43:30 GMT, Viktor Klang  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve docs as per comments
>
> src/java.base/share/classes/java/lang/StableValue.java line 582:
> 
>> 580:     static  Supplier supplier(Supplier original) {
>> 581:         Objects.requireNonNull(original);
>> 582:         return StableSupplier.of(original);
> 
> I guess if `original` is a StableSupplier then we could just return that?

This is true for all the stable functions. I will take a note of this for the next round of previews.

> src/java.base/share/classes/java/lang/StableValue.java line 614:
> 
>> 612:      * @throws IllegalArgumentException if the provided {@code size} is negative.
>> 613:      */
>> 614:     static  IntFunction intFunction(int size,
> 
> Does an intFunction of size 0 make sense?

it is similar to an empty list but even more useless.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037507369
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2037504013

From pminborg at openjdk.org  Thu Apr 10 14:10:49 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 10 Apr 2025 14:10:49 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v55]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with 20 additional commits since the last revision:

 - Update test/jdk/java/lang/StableValue/StableValueFactoriesTest.java
   
   Co-authored-by: Viktor Klang 
 - Update test/jdk/java/lang/StableValue/StableSupplierTest.java
   
   Co-authored-by: Viktor Klang 
 - Update test/jdk/java/lang/StableValue/StableMapTest.java
   
   Co-authored-by: Viktor Klang 
 - Update test/jdk/java/lang/StableValue/StableFunctionTest.java
   
   Co-authored-by: Viktor Klang 
 - Update test/jdk/java/lang/StableValue/StableIntFunctionTest.java
   
   Co-authored-by: Viktor Klang 
 - Update test/jdk/java/lang/StableValue/StableListTest.java
   
   Co-authored-by: Viktor Klang 
 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Viktor Klang 
 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Viktor Klang 
 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Viktor Klang 
 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Viktor Klang 
 - ... and 10 more: https://git.openjdk.org/jdk/compare/70a15815...2a36bb33

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/70a15815..2a36bb33

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=54
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=53-54

  Stats: 28 lines in 7 files changed: 0 ins; 0 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From pminborg at openjdk.org  Thu Apr 10 14:19:25 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 10 Apr 2025 14:19:25 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v56]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Address comments on original vs underlying

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/2a36bb33..cd654b2f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=55
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=54-55

  Stats: 50 lines in 1 file changed: 0 ins; 0 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From duke at openjdk.org  Thu Apr 10 14:26:55 2025
From: duke at openjdk.org (duke)
Date: Thu, 10 Apr 2025 14:26:55 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v32]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 28 Mar 2025 18:24:49 GMT, fabioromano1  wrote:

>> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed up `BigDecimal.sqrt()` implementation. Here is how I made it.
>> 
>> The main steps of the algorithm are as follows:
>> first argument reduce the value to an integer using the following relations:
>> 
>> x = y * 10 ^ exp
>> sqrt(x) = sqrt(y) * 10^(exp / 2) if exp is even
>> sqrt(x) = sqrt(y*10) * 10^((exp-1)/2) is exp is odd
>> 
>> Then use BigInteger.sqrt() on the reduced value to compute the numerical digits of the desired result.
>> 
>> Finally, scale back to the desired exponent range and perform any adjustment to get the preferred scale in the representation.
>
> fabioromano1 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 36 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patchBigDecimalSqrt
>  - An optimization
>  - Refine documentation
>  - Speed up computation of bitLength()
>  - An optimization
>  - Make digitLengthLower() static
>  - Optimization for integer BigDecimals detection
>  - Optimized integer BigDecimals detection
>  - Added test for scale overflow
>  - Added tests for exact results path
>  - ... and 26 more: https://git.openjdk.org/jdk/compare/34669618...378569c5

@fabioromano1 
Your change (at version 378569c56f7fde9f176ce9d18b668cff58ca2de7) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2793704357

From forax at openjdk.org  Thu Apr 10 14:33:46 2025
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 10 Apr 2025 14:33:46 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v53]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 10 Apr 2025 13:46:17 GMT, Per Minborg  wrote:

> > > ```
> > > 
> > > I will take a look at it.
> > > ```
> > 
> > 
> > As i said in another mail to core-lib this morning, it seems that the field storing the hashcode of String is not marked with @stable. That's may be the issue.
> 
> Yes. I can confirm that this is the root cause of the problem:
> 
> ```
> Benchmark                         Mode  Cnt    Score    Error  Units
> Tmp.confinedStableFunctionLoop    avgt    5  153.522 ?  6.707  ns/op
> Tmp.confinedStableMapElementLoop  avgt    5  142.780 ?  4.077  ns/op
> Tmp.confinedStableMapLoop         avgt    5  157.815 ? 17.250  ns/op
> Tmp.confinedStableValueLoop       avgt    5  142.940 ?  2.721  ns/op
> Tmp.confinedUnmodifiableMapLoop   avgt    5  142.542 ? 10.049  ns/op
> ```

Nice !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2793788502

From duke at openjdk.org  Thu Apr 10 14:37:39 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 10 Apr 2025 14:37:39 GMT
Subject: Integrated: 8341402: BigDecimal's square root optimization
In-Reply-To: 
References: 
Message-ID: 

On Wed, 2 Oct 2024 10:31:09 GMT, fabioromano1  wrote:

> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed up `BigDecimal.sqrt()` implementation. Here is how I made it.
> 
> The main steps of the algorithm are as follows:
> first argument reduce the value to an integer using the following relations:
> 
> x = y * 10 ^ exp
> sqrt(x) = sqrt(y) * 10^(exp / 2) if exp is even
> sqrt(x) = sqrt(y*10) * 10^((exp-1)/2) is exp is odd
> 
> Then use BigInteger.sqrt() on the reduced value to compute the numerical digits of the desired result.
> 
> Finally, scale back to the desired exponent range and perform any adjustment to get the preferred scale in the representation.

This pull request has now been integrated.

Changeset: c4c3edfa
Author:    fabioromano1 <51378941+fabioromano1 at users.noreply.github.com>
Committer: Raffaello Giulietti 
URL:       https://git.openjdk.org/jdk/commit/c4c3edfa964ef504f12971c5deef7c7355bdf325
Stats:     453 lines in 2 files changed: 226 ins; 187 del; 40 mod

8341402: BigDecimal's square root optimization

Reviewed-by: rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/21301

From dfuchs at openjdk.org  Thu Apr 10 14:38:33 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 10 Apr 2025 14:38:33 GMT
Subject: RFR: 8353683: [REDO] j.u.l.Handler classes create deadlock risk
 via synchronized publish() method
In-Reply-To: 
References: <2l5AHWU2u5_pJSlTHuCbW4NXM6Rzdq1vjvvoca0wKC0=.0a9cfc62-70dc-498e-816e-469ffbbca9ce@github.com>
 
Message-ID: 

On Tue, 8 Apr 2025 11:03:39 GMT, David Beaumont  wrote:

>> 8353683: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
>> 
>> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
>> 2. Add explanatory comments to various affected methods.
>> 3. Add a test to ensure deadlocks no longer occur.
>> 
>> Note that this change does not address issue in MemoryHandler (see JDK-8349208).
>
> This is a redo of https://github.com/openjdk/jdk/pull/23491 with a tiny additional edit to remove an unwanted `
` element in the public JavaDoc (see https://github.com/openjdk/jdk/pull/24504/commits/772a03e0ca08da9412b85ceb8de5adf4fb52d2ac ).

OK I ran tier1 and tier2 + logging test and got no failures. @david-beaumont can you integrate and let me know?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24504#issuecomment-2793857309

From ihse at openjdk.org  Thu Apr 10 14:46:42 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 14:46:42 GMT
Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables
 available in *.cfg files [v10]
In-Reply-To: 
References: 
 
 
Message-ID: <48XUp04EgIXYClNpiBYOVe_42cJAljCARwz1-HWUTYA=.7bdd2f12-5487-43fb-be12-c3185749a738@github.com>

On Thu, 10 Apr 2025 14:42:26 GMT, Magnus Ihse Bursie  wrote:

>> Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   Update tests and implementation to comply with the CSR (env var names are case-insesitive on Windows)
>
> src/jdk.jpackage/share/man/jpackage.md line 228:
> 
>> 226:     An expandable substring should be enclosed between the dollar
>> 227:     sign character ($) and the first following non-alphanumeric
>> 228:     character. Alternatively, it can be enclosed between "${" and "}"
> 
> This did not sit well with pandoc, that reports:
> 
> [WARNING] Could not convert TeX math ) and the first following non-alphanumeric character. Alternatively, it can be enclosed between ", rendering as TeX:
>   e enclosed between "
>                      ^
>   unexpected '"'
>   expecting "\\bangle", "\\brace", "\\brack", "\\choose", "\\displaystyle", "\\textstyle", "\\scriptstyle", "\\scriptscriptstyle", "{", "\\operatorname", letter, digit, ".", "!", "'", "''", "'''", "''''", "*", "+", ",", "-", ".", "/", ":", ":=", ";", "<", "=", ">", "?", "@", "~", "_", "^", "\\left", "\", "\\hyperref" or end of input

I'm guessing a possible fix would be to use 

`${`

or

"`${`"

instead.

Alternatively, we need to tell pandoc to not try and use any encoded TeX math in markdown files.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23923#discussion_r2037596802

From ihse at openjdk.org  Thu Apr 10 14:46:42 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 14:46:42 GMT
Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables
 available in *.cfg files [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 9 Apr 2025 20:56:03 GMT, Alexey Semenyuk  wrote:

>> jpackage app laucnher will expand environment variables in .cfg files.
>> 
>> Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and `$ROOTDIR` tokens with the corresponding path values. With this patch, any environment variable can be expanded. The syntax is shell-like `$ENV_VAR_NAME` or `${ENV_VAR_NAME}`. If `$ENV_VAR_NAME` syntax is used, the variable name stops at the first character outside of `[a-zA-Z0-9_]` character range. If `${ENV_VAR_NAME}` syntax is used, the variable name stops at the first `}` character after `${` substring. E.g:
>> | String    | Variables | Variable Values | Expanded String | Note |
>> | -------- | ------- |------- |------- |------- |
>> | 
Welcome $USER!
  | 
USER
 | 
USER=John
 | 
Welcome John!
 ||
>> | 
Welcome $USER!
  | 
USER
 | 
not set
 | 
Welcome $USER!
 | Unset variables are not expanded. |
>> | 
Welcome $USER2
 | 
USER2
   | 
USER2=John
 | 
Welcome John!
 ||
>> | 
Welcome ${USER}2!
 | 
USER
  | 
USER=John
 | 
Welcome John2!
 ||
>> | 
Welcome $USER-2!
 | 
USER
   | 
USER=John
 | 
Welcome John-2!
 ||
>> | 
Welcome ${USER-2}!
 | 
USER-2
   | 
USER-2=John
 | 
Welcome John!
 | `USER-2` is likely to be an invalid env variable name, but jpackage launcher is not validating names. |
>> 
>> `$` character combination prevents variable expansion:
>> | String    | Variables | Variable Values | Expanded String |
>> | -------- | ------- |------- |------- |
>> | 
Hello \$A! Bye $B
  | B | 
B=John
 | 
Hello $A! Bye John
 |
>> | 
Hello \${A}! Bye $B
  | B | 
B=John
 | 
Hello ${A}! Bye John
 |
>> 
>> `\` character combination escapes ``:
>> | String    | Variables | Variable Values | Expanded String |
>> | -------- | ------- |------- |------- |
>> | 
Hello \\\$A! Bye $B
  | A, B | 
A=Ana
B=John
 | 
Hello \\Ana! Bye John
 |
>> 
>> If `` character is not followed by another `` character or `$` character, it is interpreted as a regular character:
>> | String    | Expanded string |
>> | -------- | ------- |
>> |
a\\b\\c
|
a\\b\\c
|
>> 
>> 
>> Expansion is non-recursive:
>> | String    | Variables | Variable Values | Expanded String | Note |
>> | -------- | ------- |------- |------- |------- |
>> | 
Hello $A!
  | A | 
A...
>
> Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Update tests and implementation to comply with the CSR (env var names are case-insesitive on Windows)

src/jdk.jpackage/share/man/jpackage.md line 228:

> 226:     An expandable substring should be enclosed between the dollar
> 227:     sign character ($) and the first following non-alphanumeric
> 228:     character. Alternatively, it can be enclosed between "${" and "}"

This did not sit well with pandoc, that reports:

[WARNING] Could not convert TeX math ) and the first following non-alphanumeric character. Alternatively, it can be enclosed between ", rendering as TeX:
  e enclosed between "
                     ^
  unexpected '"'
  expecting "\\bangle", "\\brace", "\\brack", "\\choose", "\\displaystyle", "\\textstyle", "\\scriptstyle", "\\scriptscriptstyle", "{", "\\operatorname", letter, digit, ".", "!", "'", "''", "'''", "''''", "*", "+", ",", "-", ".", "/", ":", ":=", ";", "<", "=", ">", "?", "@", "~", "_", "^", "\\left", "\", "\\hyperref" or end of input

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23923#discussion_r2037591430

From mcimadamore at openjdk.org  Thu Apr 10 14:46:38 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 14:46:38 GMT
Subject: RFR: 8353917: jnativescan: Simplify ClassResolver [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 9 Apr 2025 16:00:52 GMT, Jorn Vernee  wrote:

>> `jnativescan` uses the `ClassResolver` class to find both system classes, as well as application classes. In principle, a class resolver supports both iterating over all classes from that particular source, as well as looking up classes by name. However, the `ClassResolver` for system classes doesn't support iterating, and the lookup functionality for `ClassResolvers` from other sources is never used (only iterating).
>> 
>> This patch proposes to split the iterating functionality out of `ClassResolver`. Clients that were using this functionality will switch to using the iteration functionality that is available on `ClassFileSource` directly (whose classes were previously being wrapped in a `ClassResolver`). As a result of this latter change, we can now also let `NativeMethodFinder` operate on individual classes. We just iterate over all the class file sources in `JNativeScanTask`, and feed individual class models to `NativeMethodFinder`. I think this is a good conceptual simplification of `NativeMethodFinder`,
>> 
>> Since `ClassResolver` is now only used for system classes, I've removed it, leaving only its single implementation: `SystemClassResolver`.
>> 
>> Testing: running `langtools_jnativescan` test suite.
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into jnativescan_Refactor
>  - bump copyright years
>  - merge ClassResolver and SystemClassResolver
>  - Simplify ClassResolver

Very nice simplification!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24493#pullrequestreview-2757126529

From mcimadamore at openjdk.org  Thu Apr 10 14:51:26 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 14:51:26 GMT
Subject: RFR: 8353917: jnativescan: Simplify ClassResolver [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 10 Apr 2025 14:43:20 GMT, Maurizio Cimadamore  wrote:

> Very nice simplification!

This seems to take advantage of the fact that, for the restricted method analysis, we only need to look at method reference entries whose owner is a system class -- because we know restricted methods are only defined there. As for native method declarations, we don't need anything -- the `native` flag will be captured directly in the method model. This is an happy coincidence (I hope we won't do something to invalidate that) -- but the simplified code captures better where the moving parts are, I think.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24493#issuecomment-2793996052

From mcimadamore at openjdk.org  Thu Apr 10 14:51:28 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 14:51:28 GMT
Subject: RFR: 8353917: jnativescan: Simplify ClassResolver [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 9 Apr 2025 16:00:52 GMT, Jorn Vernee  wrote:

>> `jnativescan` uses the `ClassResolver` class to find both system classes, as well as application classes. In principle, a class resolver supports both iterating over all classes from that particular source, as well as looking up classes by name. However, the `ClassResolver` for system classes doesn't support iterating, and the lookup functionality for `ClassResolvers` from other sources is never used (only iterating).
>> 
>> This patch proposes to split the iterating functionality out of `ClassResolver`. Clients that were using this functionality will switch to using the iteration functionality that is available on `ClassFileSource` directly (whose classes were previously being wrapped in a `ClassResolver`). As a result of this latter change, we can now also let `NativeMethodFinder` operate on individual classes. We just iterate over all the class file sources in `JNativeScanTask`, and feed individual class models to `NativeMethodFinder`. I think this is a good conceptual simplification of `NativeMethodFinder`,
>> 
>> Since `ClassResolver` is now only used for system classes, I've removed it, leaving only its single implementation: `SystemClassResolver`.
>> 
>> Testing: running `langtools_jnativescan` test suite.
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into jnativescan_Refactor
>  - bump copyright years
>  - merge ClassResolver and SystemClassResolver
>  - Simplify ClassResolver

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/NativeMethodFinder.java line 97:

> 95:             }
> 96:             Optional modelOpt = systemClassResolver.lookup(methodRef.owner());
> 97:             if (!modelOpt.isPresent()) {

Maybe add a comment here saying that restricted methods must be in system classes?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24493#discussion_r2037610289

From mullan at openjdk.org  Thu Apr 10 15:12:45 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 10 Apr 2025 15:12:45 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 7 Apr 2025 18:40:35 GMT, Roger Riggs  wrote:

>> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
>> 
>> @Deprecated(forRemoval = true, since="25")
>> Is added to each class and the existing @apiNote is converted to @deprected
>
> 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:
> 
>  - Revert "Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions."
>    SecureClassLoader.getPermissions and URLClassLoader.getPermissions are not marked as Deprecated.
>  - Merge branch 'master' into 8353641-deprecate-premission-classes
>  - Missing suppresswarnings
>  - Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions.
>    Remove dead code from ForkJoinPool.
>    Add @SuppressWarnings("remove")
>  - Remove unnecessary SuppressWarnings and correct Deprecated annotation style
>  - Update copyright in WindowsFileCopy
>  - Remove unused import of LinkPermission
>  - Updated style of @Deprecated to match most existing @Deprecated annotations
>    `since` comes before `forRemoval`
>    No spaces around `=`
>  - Add SuppressWarnings to a Windows source missed earlier.
>  - 8353641: Deprecate core library permission classes for removal
>    
>    Now that the Security Manager is permanently disabled, the following permission classes
>    in the core libraries area can be deprecated for removal as they are no longer useful:
>    FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission,
>    RuntimePermission, and SerializablePermission
>    
>    @Deprecated(forRemoval = true, since="25")
>    Is added to each class and the existing @apiNote is converted to @deprected

Marked as reviewed by mullan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24444#pullrequestreview-2757226356

From jwaters at openjdk.org  Thu Apr 10 15:17:32 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 10 Apr 2025 15:17:32 GMT
Subject: RFR: 8354189: Remove JLI_ReportErrorMessageSys on Windows
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Apr 2025 08:03:58 GMT, Matthias Baesken  wrote:

> JLI_ReportErrorMessageSys is not used any more on Windows, so we can remove it and make it UNIX-only (there a still a few remaining usages).

I was hoping to get around to using it on Windows, but oh well. I think the remaining usages might be replaceable with perror, if I am not mistaken

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24563#issuecomment-2794180037

From jwaters at openjdk.org  Thu Apr 10 15:17:42 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 10 Apr 2025 15:17:42 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 11 Nov 2024 09:51:35 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
>
> 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 eight additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into unused
>  - Neater warning silencer in proc_md.h
>  - Revert _WIN32 workaround in log_messages.c
>  - Copyright in VersionInfo.cpp
>  - Remove neutralLangId in VersionInfo.cpp
>  - Remove global memHandle, would've liked to keep it as a comment :(
>  - Merge branch 'master' into unused
>  - 8342682

Keep open

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2794181603

From mcimadamore at openjdk.org  Thu Apr 10 15:43:28 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 15:43:28 GMT
Subject: RFR: 8350075: Performance difference between SegmentAllocator
 methods [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 06:00:48 GMT, Per Minborg  wrote:

>> This PR proposes to add `@ForceInline` to the `default` methods in `SegmentAllocator` that do not already have it.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Add benchmark
>  - Merge branch 'master' into ms-add-missing-force-inline
>  - Add @ForceInline to default methods

If I'm reading the latest bench results correctly -- the gain seems to be minimal. And, if somebody defines a custom arena and overrides that allocation method, there would be no way to put `FI` back in the equation. So I'm not sure how much this is worth it TBH.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23628#issuecomment-2794288731

From alanb at openjdk.org  Thu Apr 10 15:44:25 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Apr 2025 15:44:25 GMT
Subject: RFR: 8354189: Remove JLI_ReportErrorMessageSys on Windows
In-Reply-To: 
References: 
Message-ID: <_h-nvBgAg_d_PeQVQYIjpqchqHuWRoxinf3P2MRiSDs=.5cc51ba6-3123-401b-bbe4-c8108b5a57c0@github.com>

On Thu, 10 Apr 2025 08:03:58 GMT, Matthias Baesken  wrote:

> JLI_ReportErrorMessageSys is not used any more on Windows, so we can remove it and make it UNIX-only (there a still a few remaining usages).

I think this looks okay, can you update the copyright header dates before you integrate.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24563#pullrequestreview-2757328338

From iklam at openjdk.org  Thu Apr 10 15:53:35 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 10 Apr 2025 15:53:35 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v5]
In-Reply-To: 
References: 
 <9nX8O13jWi7qORu4uO-ppDmlph2W2lH1VVIKFP3-Gt8=.46545db1-b218-497d-b4ef-546410b09b9b@github.com>
 
 
 
Message-ID: 

On Wed, 9 Apr 2025 16:43:39 GMT, Timofei Pushkin  wrote:

>> I've actually noticed a problem here. I assumed that registered classes are always loaded by JDK's built-in class loaders (bootstrap, `jdk.internal.loader.ClassLoaders$PlatformClassLoader` or `jdk.internal.loader.ClassLoaders$AppClassLoader`). But in reality when the system class loader is user-provided (via `-Djava.system.class.loader=`) classes loaded by it are still considered registered. This is a problem because such user-provided class loader may not delegate to real built-in class loaders.
>> 
>> For example:
>> - Let C= be a class C named N defined by class loader L
>> - Let AppL be the built-in system class loader and SysL be the user-provided system class loader
>> - Let U be an unregistered class which extends a registered 
>> - Let SysL be able to load a registered  when requested (i.e. SysL doesn't delegate when loading a class named S)
>> - When `UnregisteredClassLoader` will be loading U it will delegate the loading of its super named S to SysL and thus  will become a super of U instead of  ? this is not correct
>> 
>> This won't be a problem if only classes loaded by the real built-in class loaders would be considered registered because such class loaders always delegate first (the 4th bullet above won't be possible), and thus it doesn't matter which of these loaders was used for delegation by the class loader which defined U.
>> 
>> This can't be fixed by just making `jdk.internal.loader.ClassLoaders$AppClassLoader` a parent of `UnregisteredClassLoader` and making `UnregisteredClassLoader.findClass(name)` return `getSystemClassLoader().loadClass(name)` because then the case when U extends  will not be handeled correctly ( will be used instead of ).
>> 
>> So it looks like I have to revert this delegation-based approach and use the old way. I'll also write a test from the above example to see if I am correct first.
>
> I've realized that my example cannot be expressed in the current class list format since the format doesn't distinguish between  and , only that S is not unregistered. The existing implementation will always use  as will the new one. It feels like a flaw to me but it is not a flaw of this patch.

Currently we have some restrictions if`-Djava.system.class.loader=` is specified

- we disable full module graph archiving: https://github.com/openjdk/jdk/blob/0e223f1456c14efdb423595bee3444d5e26db7c6/src/hotspot/share/cds/cdsConfig.cpp#L286
- we disable loading archived classes for platform and system loaders: https://github.com/openjdk/jdk/blob/0e223f1456c14efdb423595bee3444d5e26db7c6/src/hotspot/share/cds/filemap.cpp#L1874-L1886

I think we should extend this limitation further (in a separate issue)

- At dump time, dump only boot classes (no platform, system or unregistered)
- At run time, load only boot classes (no platform, system or unregistered)

I filed [JDK-8354315](https://bugs.openjdk.org/browse/JDK-8354315)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2037729803

From mcimadamore at openjdk.org  Thu Apr 10 15:55:35 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 15:55:35 GMT
Subject: RFR: 8348556: Inlining fails earlier for
 MemorySegment::reinterpret [v6]
In-Reply-To: <8GSYKwHUhVFL-XjxKB9SzUyiEXVcGWnxoEr6YTnZfPE=.080d6c74-505e-41c0-84ad-2fabe5356365@github.com>
References: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
 <6wb-C25gjMYaQZXn2BFAQ2okygXAiHNxciy-zmDsy9M=.7555f6bb-2112-42d8-87ef-4ab63fab6d62@github.com>
 <8GSYKwHUhVFL-XjxKB9SzUyiEXVcGWnxoEr6YTnZfPE=.080d6c74-505e-41c0-84ad-2fabe5356365@github.com>
Message-ID: 

On Tue, 8 Apr 2025 12:13:25 GMT, Per Minborg  wrote:

> Baseline:
> 
> ```
> Benchmark                            (offsetCount)  (segmentSize)   Mode  Cnt        Score       Error  Units
> FFMVarHandleInlineTest.t0_reference           2048           1024  thrpt   25  1552613.262 ? 14295.035  ops/s
> FFMVarHandleInlineTest.t1_level8              2048           1024  thrpt   25  1558465.228 ?  8458.874  ops/s
> FFMVarHandleInlineTest.t2_level9              2048           1024  thrpt   25  1542009.100 ? 10240.173  ops/s
> FFMVarHandleInlineTest.t3_level10             2048           1024  thrpt   25  1553407.503 ? 10834.133  ops/s
> FFMVarHandleInlineTest.t4_level11             2048           1024  thrpt   25    87666.558 ?   765.848  ops/s. <-- We hit the inline limit here
> ```
> 
> Patch without `Object` changes:
> 
> ```
> Benchmark                         (offsetCount)  (segmentSize)   Mode  Cnt       Score      Error  Units
> FFMVarHandleInlineTest.t_level11           2048           1024  thrpt    6  149221.636 ? 1928.957  ops/s
> FFMVarHandleInlineTest.t_level12           2048           1024  thrpt    6   74478.268 ? 1093.429  ops/s
> FFMVarHandleInlineTest.t_level13           2048           1024  thrpt    6   74490.972 ?  623.857  ops/s
> FFMVarHandleInlineTest.t_level14           2048           1024  thrpt    6   69637.549 ? 2497.253  ops/s
> FFMVarHandleInlineTest.t_level15           2048           1024  thrpt    6    3495.106 ?   87.465  ops/s
> ```
> 
> Patch with `Object` changes:
> 
> ```
> Benchmark                         (offsetCount)  (segmentSize)   Mode  Cnt       Score      Error  Units
> FFMVarHandleInlineTest.t_level11           2048           1024  thrpt    6  1545991.924 ? 21206.450  ops/s
> FFMVarHandleInlineTest.t_level12           2048           1024  thrpt    6  1542234.193 ? 18002.511  ops/s
> FFMVarHandleInlineTest.t_level13           2048           1024  thrpt    6  1542601.822 ? 15041.864  ops/s
> FFMVarHandleInlineTest.t_level14           2048           1024  thrpt    6   179053.325 ?  2496.002  ops/s
> FFMVarHandleInlineTest.t_level15           2048           1024  thrpt    6     3433.861 ?   165.847  ops/s
> ```

am I reading this the right way around? Baseline is faster than the patched version?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23460#issuecomment-2794329053

From mcimadamore at openjdk.org  Thu Apr 10 15:55:37 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 15:55:37 GMT
Subject: RFR: 8348556: Inlining fails earlier for
 MemorySegment::reinterpret [v7]
In-Reply-To: 
References: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
 
Message-ID: 

On Tue, 8 Apr 2025 12:24:41 GMT, Per Minborg  wrote:

>> This PR proposes to add some `@ForceInline` annotations in the `Module` class in order to assist inlining of FFM var/method handles.
>> 
>> There are also some changes in other classes which, if implemented, can take us three additional levels of inlining. I drew a line there. There is a tradeoff with adding `@ForceInline` and just trying to get as deep as possible for a specific use case is probably not the best idea. 
>> 
>> Updating the `j.l.Object` constructor is crucial for the higher depths.
>> 
>> Tested and passed tier1-3
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reintroduce Object changes

src/java.base/share/classes/java/lang/Module.java line 180:

> 178:      * @jls 7.7.5 Unnamed Modules
> 179:      */
> 180:     @ForceInline

Doesn't the `ensureNativeAccess` code only depend on this one? Also, I'm having an hard time thinking that C2 can't inline this simple method? Isn't this an "accessor" ?

src/java.base/share/classes/jdk/internal/foreign/MemorySessionImpl.java line 213:

> 211:      * a confined session and this method is called outside the owner thread.
> 212:      */
> 213:     @ForceInline

I presume this is added because it's called by the reinterpret implementation?

src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java line 100:

> 98: 
> 99:     @Override
> 100:     @ForceInline

I'm not sure this is needed -- this is an "accessor" method - C2 typically inline those. But, do we depend on `maxAlignMask` for reinterpret?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23460#discussion_r2037723817
PR Review Comment: https://git.openjdk.org/jdk/pull/23460#discussion_r2037726741
PR Review Comment: https://git.openjdk.org/jdk/pull/23460#discussion_r2037730266

From liach at openjdk.org  Thu Apr 10 15:55:35 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 10 Apr 2025 15:55:35 GMT
Subject: RFR: 8350462: MethodTypeForm.LF_INTERPRET can cache the MemberName
 instead [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 6 Apr 2025 08:09:27 GMT, Zihao Lin  wrote:

>> Modify the cache in MethodTypeForm that currently stores the LF_INTERPRET Lambda form. Instead of caching the entire LambdaForm, change it to store a SoftReference. This will avoid unnecessary memory usage.
>
> Zihao Lin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove LF_INTERPRET

Marked as reviewed by liach (Reviewer).

One unrelated client test failed in tier 1-3, everything else was fine.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24468#pullrequestreview-2757360093
PR Comment: https://git.openjdk.org/jdk/pull/24468#issuecomment-2794327580

From duke at openjdk.org  Thu Apr 10 15:56:37 2025
From: duke at openjdk.org (duke)
Date: Thu, 10 Apr 2025 15:56:37 GMT
Subject: RFR: 8353683: [REDO] j.u.l.Handler classes create deadlock risk
 via synchronized publish() method
In-Reply-To: <2l5AHWU2u5_pJSlTHuCbW4NXM6Rzdq1vjvvoca0wKC0=.0a9cfc62-70dc-498e-816e-469ffbbca9ce@github.com>
References: <2l5AHWU2u5_pJSlTHuCbW4NXM6Rzdq1vjvvoca0wKC0=.0a9cfc62-70dc-498e-816e-469ffbbca9ce@github.com>
Message-ID: <8AdQED_a5kWvB8y20Uf7idJz-QXv5Uonj8P5kmxT4IE=.3a298857-e031-4521-ae9d-80ecf7483e19@github.com>

On Tue, 8 Apr 2025 11:00:27 GMT, David Beaumont  wrote:

> 8353683: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

@david-beaumont 
Your change (at version 772a03e0ca08da9412b85ceb8de5adf4fb52d2ac) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24504#issuecomment-2794332106

From mcimadamore at openjdk.org  Thu Apr 10 15:58:29 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 15:58:29 GMT
Subject: RFR: 8348556: Inlining fails earlier for
 MemorySegment::reinterpret [v6]
In-Reply-To: 
References: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
 <6wb-C25gjMYaQZXn2BFAQ2okygXAiHNxciy-zmDsy9M=.7555f6bb-2112-42d8-87ef-4ab63fab6d62@github.com>
 <8GSYKwHUhVFL-XjxKB9SzUyiEXVcGWnxoEr6YTnZfPE=.080d6c74-505e-41c0-84ad-2fabe5356365@github.com>
 
Message-ID: <-Fi-Auy3YpXOAzmBgoQXZzK5kXpPGKXYqnEv1h0Cv6k=.2d741644-aea8-463a-85b5-b1652f48f984@github.com>

On Thu, 10 Apr 2025 15:52:38 GMT, Maurizio Cimadamore  wrote:

> > Baseline:
> > ```
> > Benchmark                            (offsetCount)  (segmentSize)   Mode  Cnt        Score       Error  Units
> > FFMVarHandleInlineTest.t0_reference           2048           1024  thrpt   25  1552613.262 ? 14295.035  ops/s
> > FFMVarHandleInlineTest.t1_level8              2048           1024  thrpt   25  1558465.228 ?  8458.874  ops/s
> > FFMVarHandleInlineTest.t2_level9              2048           1024  thrpt   25  1542009.100 ? 10240.173  ops/s
> > FFMVarHandleInlineTest.t3_level10             2048           1024  thrpt   25  1553407.503 ? 10834.133  ops/s
> > FFMVarHandleInlineTest.t4_level11             2048           1024  thrpt   25    87666.558 ?   765.848  ops/s. <-- We hit the inline limit here
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > Patch without `Object` changes:
> > ```
> > Benchmark                         (offsetCount)  (segmentSize)   Mode  Cnt       Score      Error  Units
> > FFMVarHandleInlineTest.t_level11           2048           1024  thrpt    6  149221.636 ? 1928.957  ops/s
> > FFMVarHandleInlineTest.t_level12           2048           1024  thrpt    6   74478.268 ? 1093.429  ops/s
> > FFMVarHandleInlineTest.t_level13           2048           1024  thrpt    6   74490.972 ?  623.857  ops/s
> > FFMVarHandleInlineTest.t_level14           2048           1024  thrpt    6   69637.549 ? 2497.253  ops/s
> > FFMVarHandleInlineTest.t_level15           2048           1024  thrpt    6    3495.106 ?   87.465  ops/s
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > Patch with `Object` changes:
> > ```
> > Benchmark                         (offsetCount)  (segmentSize)   Mode  Cnt       Score      Error  Units
> > FFMVarHandleInlineTest.t_level11           2048           1024  thrpt    6  1545991.924 ? 21206.450  ops/s
> > FFMVarHandleInlineTest.t_level12           2048           1024  thrpt    6  1542234.193 ? 18002.511  ops/s
> > FFMVarHandleInlineTest.t_level13           2048           1024  thrpt    6  1542601.822 ? 15041.864  ops/s
> > FFMVarHandleInlineTest.t_level14           2048           1024  thrpt    6   179053.325 ?  2496.002  ops/s
> > FFMVarHandleInlineTest.t_level15           2048           1024  thrpt    6     3433.861 ?   165.847  ops/s
> > ```
> 
> am I reading this the right way around? Baseline is faster than the patched version?

Ah ok - you gain 3-4 more levels. Again... I'm really not sure about how reliable this all is. I'd suggest for somebody like @iwanowww  to validate this -- while JMH gives some better results here, I'm skeptical that real world usage is going to see any difference here, as the benchmarking conditions seem a little too on the artificial side.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23460#issuecomment-2794338281

From duke at openjdk.org  Thu Apr 10 16:02:36 2025
From: duke at openjdk.org (duke)
Date: Thu, 10 Apr 2025 16:02:36 GMT
Subject: RFR: 8350462: MethodTypeForm.LF_INTERPRET can cache the MemberName
 instead [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 6 Apr 2025 08:09:27 GMT, Zihao Lin  wrote:

>> Modify the cache in MethodTypeForm that currently stores the LF_INTERPRET Lambda form. Instead of caching the entire LambdaForm, change it to store a SoftReference. This will avoid unnecessary memory usage.
>
> Zihao Lin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove LF_INTERPRET

@linzihao1999 
Your change (at version 3ce154ea17e5bf3de2bb27f89edd012b016cacf3) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24468#issuecomment-2794353403

From duke at openjdk.org  Thu Apr 10 16:03:44 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 10 Apr 2025 16:03:44 GMT
Subject: Integrated: 8353683: [REDO] j.u.l.Handler classes create deadlock risk
 via synchronized publish() method
In-Reply-To: <2l5AHWU2u5_pJSlTHuCbW4NXM6Rzdq1vjvvoca0wKC0=.0a9cfc62-70dc-498e-816e-469ffbbca9ce@github.com>
References: <2l5AHWU2u5_pJSlTHuCbW4NXM6Rzdq1vjvvoca0wKC0=.0a9cfc62-70dc-498e-816e-469ffbbca9ce@github.com>
Message-ID: 

On Tue, 8 Apr 2025 11:00:27 GMT, David Beaumont  wrote:

> 8353683: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

This pull request has now been integrated.

Changeset: 36e11b68
Author:    David Beaumont 
Committer: Daniel Fuchs 
URL:       https://git.openjdk.org/jdk/commit/36e11b6827d5065f75a52887e1200b22cb3cdd40
Stats:     453 lines in 8 files changed: 430 ins; 8 del; 15 mod

8353683: [REDO] j.u.l.Handler classes create deadlock risk via synchronized publish() method

Reviewed-by: smarks

-------------

PR: https://git.openjdk.org/jdk/pull/24504

From iklam at openjdk.org  Thu Apr 10 16:04:31 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 10 Apr 2025 16:04:31 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v5]
In-Reply-To: 
References: 
 <9nX8O13jWi7qORu4uO-ppDmlph2W2lH1VVIKFP3-Gt8=.46545db1-b218-497d-b4ef-546410b09b9b@github.com>
 
 
 
 
Message-ID: 

On Thu, 10 Apr 2025 15:50:56 GMT, Ioi Lam  wrote:

>> I've realized that my example cannot be expressed in the current class list format since the format doesn't distinguish between  and , only that S is not unregistered. The existing implementation will always use  as will the new one. It feels like a flaw to me but it is not a flaw of this patch.
>
> Currently we have some restrictions if`-Djava.system.class.loader=` is specified
> 
> - we disable full module graph archiving: https://github.com/openjdk/jdk/blob/0e223f1456c14efdb423595bee3444d5e26db7c6/src/hotspot/share/cds/cdsConfig.cpp#L286
> - we disable loading archived classes for platform and system loaders: https://github.com/openjdk/jdk/blob/0e223f1456c14efdb423595bee3444d5e26db7c6/src/hotspot/share/cds/filemap.cpp#L1874-L1886
> 
> I think we should extend this limitation further (in a separate issue)
> 
> - At dump time, dump only boot classes (no platform, system or unregistered)
> - At run time, load only boot classes (no platform, system or unregistered)
> 
> I filed [JDK-8354315](https://bugs.openjdk.org/browse/JDK-8354315)

In the current JDK (with or without this patch), in your scenario, I think the name "S" will be printed twice with two different IDs. If a Child class named "C" is loaded by a custom loader, it will refer to one of the IDs. Depending on the order of loading, it might refer to the first or the second ID.

During dump time, we will try to load this class twice, but both attempts will result in the same class (defined by the user-defined system class loader). When resolving the unregistered class, using either ID will give you the correct super class ...

Anyway, this seems too fragile. I think we should fix [JDK-8354315](https://bugs.openjdk.org/browse/JDK-8354315) before integrating this patch. Or, maybe we can include the fixes of that bug in this PR as well (and then close that bug as a duplicate of this one). What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2037756333

From iklam at openjdk.org  Thu Apr 10 16:07:32 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 10 Apr 2025 16:07:32 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 9 Apr 2025 18:37:15 GMT, Timofei Pushkin  wrote:

>> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app.
>> 
>> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible.
>
> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove findClass, extend explanation comments

test/hotspot/jtreg/runtime/cds/appcds/customLoader/ClassFromClasspath.java line 53:

> 51:         out.shouldContain("unreg CustomLoadee");
> 52:     }
> 53: }

For completeness, I think we should have a more complicated scenario:

- load CustomLoadee in both the app loader and a custom loader
- load CustomLoadeeChild in the custom loader. Its super class should be the one defined in the custom loader

At run time, verify that CustomLoadeeChild is archived and its super class is defined in the custom loader

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2037764057

From asemenyuk at openjdk.org  Thu Apr 10 16:54:39 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 10 Apr 2025 16:54:39 GMT
Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables
 available in *.cfg files [v10]
In-Reply-To: <48XUp04EgIXYClNpiBYOVe_42cJAljCARwz1-HWUTYA=.7bdd2f12-5487-43fb-be12-c3185749a738@github.com>
References: 
 
 
 <48XUp04EgIXYClNpiBYOVe_42cJAljCARwz1-HWUTYA=.7bdd2f12-5487-43fb-be12-c3185749a738@github.com>
Message-ID: 

On Thu, 10 Apr 2025 14:44:06 GMT, Magnus Ihse Bursie  wrote:

>> src/jdk.jpackage/share/man/jpackage.md line 228:
>> 
>>> 226:     An expandable substring should be enclosed between the dollar
>>> 227:     sign character ($) and the first following non-alphanumeric
>>> 228:     character. Alternatively, it can be enclosed between "${" and "}"
>> 
>> This did not sit well with pandoc, that reports:
>> 
>> [WARNING] Could not convert TeX math ) and the first following non-alphanumeric character. Alternatively, it can be enclosed between ", rendering as TeX:
>>   e enclosed between "
>>                      ^
>>   unexpected '"'
>>   expecting "\\bangle", "\\brace", "\\brack", "\\choose", "\\displaystyle", "\\textstyle", "\\scriptstyle", "\\scriptscriptstyle", "{", "\\operatorname", letter, digit, ".", "!", "'", "''", "'''", "''''", "*", "+", ",", "-", ".", "/", ":", ":=", ";", "<", "=", ">", "?", "@", "~", "_", "^", "\\left", "\", "\\hyperref" or end of input
>
> I'm guessing a possible fix would be to use 
> 
> `${`
> 
> or
> 
> "`${`"
> 
> instead.
> 
> Alternatively, we need to tell pandoc to not try and use any encoded TeX math in markdown files.

I filed https://bugs.openjdk.org/browse/JDK-8354320 to fix the warning

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23923#discussion_r2037868095

From jvernee at openjdk.org  Thu Apr 10 17:07:21 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 10 Apr 2025 17:07:21 GMT
Subject: RFR: 8353917: jnativescan: Simplify ClassResolver [v3]
In-Reply-To: 
References: 
Message-ID: 

> `jnativescan` uses the `ClassResolver` class to find both system classes, as well as application classes. In principle, a class resolver supports both iterating over all classes from that particular source, as well as looking up classes by name. However, the `ClassResolver` for system classes doesn't support iterating, and the lookup functionality for `ClassResolvers` from other sources is never used (only iterating).
> 
> This patch proposes to split the iterating functionality out of `ClassResolver`. Clients that were using this functionality will switch to using the iteration functionality that is available on `ClassFileSource` directly (whose classes were previously being wrapped in a `ClassResolver`). As a result of this latter change, we can now also let `NativeMethodFinder` operate on individual classes. We just iterate over all the class file sources in `JNativeScanTask`, and feed individual class models to `NativeMethodFinder`. I think this is a good conceptual simplification of `NativeMethodFinder`,
> 
> Since `ClassResolver` is now only used for system classes, I've removed it, leaving only its single implementation: `SystemClassResolver`.
> 
> Testing: running `langtools_jnativescan` test suite.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24493/files
  - new: https://git.openjdk.org/jdk/pull/24493/files/976605ba..85e0f2d2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24493&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24493&range=01-02

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24493.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24493/head:pull/24493

PR: https://git.openjdk.org/jdk/pull/24493

From jvernee at openjdk.org  Thu Apr 10 17:09:27 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 10 Apr 2025 17:09:27 GMT
Subject: RFR: 8353917: jnativescan: Simplify ClassResolver [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <_lVXgthKL005349ipRST1iXjZmEKbLh976j0HXkryYg=.70250ae1-3e0f-4664-a8db-ba745a18656c@github.com>

On Thu, 10 Apr 2025 14:48:59 GMT, Maurizio Cimadamore  wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Merge branch 'master' into jnativescan_Refactor
>>  - bump copyright years
>>  - merge ClassResolver and SystemClassResolver
>>  - Simplify ClassResolver
>
> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/NativeMethodFinder.java line 97:
> 
>> 95:             }
>> 96:             Optional modelOpt = systemClassResolver.lookup(methodRef.owner());
>> 97:             if (!modelOpt.isPresent()) {
> 
> Maybe add a comment here saying that restricted methods must be in system classes?

I've added a comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24493#discussion_r2037892007

From naoto at openjdk.org  Thu Apr 10 17:12:26 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 10 Apr 2025 17:12:26 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie  wrote:

> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
> 
> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
> 
> Methodology used: 
> 
> I have run four different tools for using different heuristics for determining the encoding of a file:
> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
> * enca (targeted towards obscure code pages)
> * libmagic / `file  --mime-encoding`
> 
> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
> 
> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
> * All files where at least one tool claimed it to be UTF-8
> * All files where at least one tool claimed it to be *not* UTF-8
> 
> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
> 
> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure binary files, but without any telling exten...

src/java.desktop/share/legal/lcms.md line 72:

> 70: Mateusz Jurczyk (Google)
> 71: Paul Miller
> 72: S?bastien L?on

I cannot comment on capitalization here, but if we wanted to lowercase them, should they be e-grave instead of e-acute?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2037895884

From jvernee at openjdk.org  Thu Apr 10 17:17:31 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 10 Apr 2025 17:17:31 GMT
Subject: RFR: 8350462: MethodTypeForm.LF_INTERPRET can cache the MemberName
 instead [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 6 Apr 2025 08:09:27 GMT, Zihao Lin  wrote:

>> Modify the cache in MethodTypeForm that currently stores the LF_INTERPRET Lambda form. Instead of caching the entire LambdaForm, change it to store a SoftReference. This will avoid unnecessary memory usage.
>
> Zihao Lin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove LF_INTERPRET

Looks good to me. Nice simplification!

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24468#pullrequestreview-2757647710

From liach at openjdk.org  Thu Apr 10 17:24:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 10 Apr 2025 17:24:38 GMT
Subject: RFR: 8350462: MethodTypeForm.LF_INTERPRET can cache the MemberName
 instead [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 6 Apr 2025 08:09:27 GMT, Zihao Lin  wrote:

>> Modify the cache in MethodTypeForm that currently stores the LF_INTERPRET Lambda form. Instead of caching the entire LambdaForm, change it to store a SoftReference. This will avoid unnecessary memory usage.
>
> Zihao Lin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove LF_INTERPRET

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24468#issuecomment-2794612237

From duke at openjdk.org  Thu Apr 10 17:24:38 2025
From: duke at openjdk.org (Zihao Lin)
Date: Thu, 10 Apr 2025 17:24:38 GMT
Subject: Integrated: 8350462: MethodTypeForm.LF_INTERPRET can cache the
 MemberName instead
In-Reply-To: 
References: 
Message-ID: 

On Sat, 5 Apr 2025 14:26:13 GMT, Zihao Lin  wrote:

> Modify the cache in MethodTypeForm that currently stores the LF_INTERPRET Lambda form. Instead of caching the entire LambdaForm, change it to store a SoftReference. This will avoid unnecessary memory usage.

This pull request has now been integrated.

Changeset: dc249be2
Author:    Zihao Lin 
Committer: Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/dc249be2474d8711ca6e92ec139b4b6f0aa92e6e
Stats:     32 lines in 2 files changed: 17 ins; 10 del; 5 mod

8350462: MethodTypeForm.LF_INTERPRET can cache the MemberName instead

Reviewed-by: liach, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/24468

From rgiulietti at openjdk.org  Thu Apr 10 17:26:30 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 10 Apr 2025 17:26:30 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 17:09:27 GMT, Naoto Sato  wrote:

>> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
>> 
>> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
>> 
>> Methodology used: 
>> 
>> I have run four different tools for using different heuristics for determining the encoding of a file:
>> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
>> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
>> * enca (targeted towards obscure code pages)
>> * libmagic / `file  --mime-encoding`
>> 
>> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
>> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
>> 
>> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
>> * All files where at least one tool claimed it to be UTF-8
>> * All files where at least one tool claimed it to be *not* UTF-8
>> 
>> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
>> 
>> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure...
>
> src/java.desktop/share/legal/lcms.md line 72:
> 
>> 70: Mateusz Jurczyk (Google)
>> 71: Paul Miller
>> 72: S?bastien L?on
> 
> I cannot comment on capitalization here, but if we wanted to lowercase them, should they be e-grave instead of e-acute?

If this is a French name, it's e acute: ?.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2037917708

From erikj at openjdk.org  Thu Apr 10 17:37:26 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 10 Apr 2025 17:37:26 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: 
References: 
Message-ID: <4fRjwM-P0XuOWk9QjYl9zji51zLn7wwsFKlo7tJt3JM=.976560e0-39c6-4633-bc8d-279deb1ebea3@github.com>

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie  wrote:

> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
> 
> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
> 
> Methodology used: 
> 
> I have run four different tools for using different heuristics for determining the encoding of a file:
> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
> * enca (targeted towards obscure code pages)
> * libmagic / `file  --mime-encoding`
> 
> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
> 
> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
> * All files where at least one tool claimed it to be UTF-8
> * All files where at least one tool claimed it to be *not* UTF-8
> 
> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
> 
> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure binary files, but without any telling exten...

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24566#pullrequestreview-2757703868

From naoto at openjdk.org  Thu Apr 10 17:41:25 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 10 Apr 2025 17:41:25 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: 
References: 
Message-ID: <7hmmP0I0kH0UiF8cV-CkNnpdQFkddrt3TYEkFltoj8U=.3bf6bcbf-3771-4628-82e0-f678f7366d8a@github.com>

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie  wrote:

> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
> 
> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
> 
> Methodology used: 
> 
> I have run four different tools for using different heuristics for determining the encoding of a file:
> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
> * enca (targeted towards obscure code pages)
> * libmagic / `file  --mime-encoding`
> 
> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
> 
> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
> * All files where at least one tool claimed it to be UTF-8
> * All files where at least one tool claimed it to be *not* UTF-8
> 
> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
> 
> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure binary files, but without any telling exten...

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24566#pullrequestreview-2757716905

From darcy at openjdk.org  Thu Apr 10 17:56:45 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 10 Apr 2025 17:56:45 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v31]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 18 Mar 2025 14:46:01 GMT, fabioromano1  wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   An optimization
>
> This comment is to avoid closing this PR.

> @fabioromano1 Thanks so much for your great work and patience!

Same!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2794695562

From liach at openjdk.org  Thu Apr 10 18:01:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 10 Apr 2025 18:01:57 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v57]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
 
Message-ID: <17CDLKZYKCAtHgc4vB-Y9o1k266gkM4Sy7ZrmUfsjvU=.9328b2a1-36bd-45c8-beab-3b984fb65762@github.com>

On Sun, 6 Apr 2025 10:50:50 GMT, Luca Kellermann  wrote:

>> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits:
>> 
>>  - Merge branch 'master' into primitive-patterns
>>  - Update summary in ExactnessConversionsSupportTest
>>  - Address review by Jan
>>  - Remove redundant null check  and introduce a const boolean for unconditionally exact pairs
>>  - Small fix in Javadoc
>>  - Tidy up Javadoc of Lower.visitTypeTest
>>  - Tidy up Javadoc of IllegalArgumentException in typeSwitch
>>  - Improve readability in SwitchBootstraps
>>  - Update year
>>  - Cleanup redundant clone
>>  - ... and 68 more: https://git.openjdk.org/jdk/compare/ec56c72b...f68748b1
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 676:
> 
>> 674:         }
>> 675:         else if (selectorType.equals(targetType) ||
>> 676:                 ((selectorType.equals(byte.class) && !targetType.equals(char.class)) ||
> 
> Suggestion:
> 
>                 ((selectorType.equals(byte.class) && targetType.isPrimitve() && !targetType.equals(boolean.class) && !targetType.equals(char.class)) ||
> 
> Otherwise, `SwitchBootstraps.typeSwitch` produces wrong results for `byte`:
> 
> var l = MethodHandles.lookup();
> var shortType = MethodType.methodType(int.class, short.class, int.class);
> var byteType = MethodType.methodType(int.class, byte.class, int.class);
> 
> CallSite shortSwitch = SwitchBootstraps.typeSwitch(l, "", shortType, String.class);
> CallSite byteSwitch = SwitchBootstraps.typeSwitch(l, "", byteType, String.class);
> 
> int shortIndex = (int) shortSwitch.getTarget().invokeExact((short) 1, 0);
> int byteIndex = (int) byteSwitch.getTarget().invokeExact((byte) 1, 0);
> 
> System.out.println(shortIndex == 1); // true
> System.out.println(byteIndex == 1); // false
> System.out.println(byteIndex); // 0
> 
> This would cause this code to misbehave (if it would compile, which it doesn't):
> 
> byte b = 1;
> switch (b) {
>     case String s -> System.out.println("How did we get here? byte is " + s.getClass());
> }
> 
> So it isn't really a problem with `javac` but could cause problems for other users of `SwitchBootstraps`.

A JBS issue has been created at https://bugs.openjdk.org/browse/JDK-8354323

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r2037974588

From jlahoda at openjdk.org  Thu Apr 10 18:04:54 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 10 Apr 2025 18:04:54 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v5]
In-Reply-To: 
References: 
Message-ID: 

> This is a patch to finalize the module imports feature. Please see:
> https://bugs.openjdk.org/browse/JDK-8344700

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review feedback: cleanup formatting in ModuleInfo.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23801/files
  - new: https://git.openjdk.org/jdk/pull/23801/files/d66703c1..029e0dd5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23801&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23801&range=03-04

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23801/head:pull/23801

PR: https://git.openjdk.org/jdk/pull/23801

From jlahoda at openjdk.org  Thu Apr 10 18:04:54 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 10 Apr 2025 18:04:54 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 9 Apr 2025 17:52:26 GMT, Alan Bateman  wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review feedback - avoiding hardcoded constants.
>
> src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 415:
> 
>> 413:                 if (major >= 54
>> 414:                     && mods.contains(Requires.Modifier.STATIC)) {
>> 415:                     String flagName = "ACC_STATIC_PHASE";
> 
> A minor comment on the style here, do you mind combin L413+414 as it will make it easier to read. The change is okay of course.

I did this:
https://github.com/openjdk/jdk/pull/23801/commits/029e0dd59c7160f4fe043dd7191860b067ca787c
Please let me know if something more/different is needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23801#discussion_r2037978491

From smarks at openjdk.org  Thu Apr 10 18:14:52 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 10 Apr 2025 18:14:52 GMT
Subject: RFR: 8351740: Clean up some code around initialization of encoding
 properties [v3]
In-Reply-To: 
References: 
Message-ID: 

> Some of the code that creates various encoding properties at JVM initialization time, such as file.encoding and native.encoding, could use some cleaning up. Cleanup is fairly minimal and should be mostly behavior-preserving. Changes include the following:
> 
> * In the java_props.h and java_props_md.c files, add documentation and asserts that the sprops.encoding and sprops.sun_jnu_encoding members are always set to non-NULL by the platform-specific code.
> 
> * In SystemProps.java, remove a null check that is now extraneous based on the above assertion.
> 
> * In SystemProps.java, rearrange logic (with no behavior change) around handling of the "COMPAT" value for the file.encoding property.
> 
> * In SystemProps.Raw, rename the platform properties array index from _file_encoding_NDX to _native_encoding_NDX.
> 
> * In SystemProps.Raw.cmdProperties(), adjust the HashMap size computation. This should actually avoid resizing of the HashMap (unlike the earlier code).
> 
> * Adjust various comments in several places for clarity and correctness.

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Update copyrights; change var to String in a couple places.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24463/files
  - new: https://git.openjdk.org/jdk/pull/24463/files/e8f3d35e..61420276

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24463&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24463&range=01-02

  Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24463.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24463/head:pull/24463

PR: https://git.openjdk.org/jdk/pull/24463

From smarks at openjdk.org  Thu Apr 10 18:14:52 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 10 Apr 2025 18:14:52 GMT
Subject: RFR: 8351740: Clean up some code around initialization of encoding
 properties [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 10 Apr 2025 08:31:40 GMT, Alan Bateman  wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment from file.encoding to native.encoding
>
> src/java.base/share/classes/jdk/internal/util/SystemProps.java line 79:
> 
>> 77:         // Platform defined encodings cannot be overridden on the command line
>> 78:         put(props, "sun.jnu.encoding", raw.propDefault(Raw._sun_jnu_encoding_NDX));
>> 79:         var nativeEncoding = raw.propDefault(Raw._native_encoding_NDX);
> 
> I'd prefer not see "var" here, only because it's not immediately clear that nativeEncoding is a String.

I changed this `var` to `String` and also another occurrence a few lines below.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24463#discussion_r2037992031

From smarks at openjdk.org  Thu Apr 10 18:14:52 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 10 Apr 2025 18:14:52 GMT
Subject: RFR: 8351740: Clean up some code around initialization of encoding
 properties [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: <5fFRHPUot9kKjZVDySeFZuQuNr3O-X0n1xi4cFltfBo=.044b99a7-a0b0-46c9-b4ad-58681f3807fc@github.com>

On Thu, 10 Apr 2025 18:11:06 GMT, Stuart Marks  wrote:

>> src/java.base/share/classes/jdk/internal/util/SystemProps.java line 79:
>> 
>>> 77:         // Platform defined encodings cannot be overridden on the command line
>>> 78:         put(props, "sun.jnu.encoding", raw.propDefault(Raw._sun_jnu_encoding_NDX));
>>> 79:         var nativeEncoding = raw.propDefault(Raw._native_encoding_NDX);
>> 
>> I'd prefer not see "var" here, only because it's not immediately clear that nativeEncoding is a String.
>
> I changed this `var` to `String` and also another occurrence a few lines below.

Also, I updated copyrights.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24463#discussion_r2037992391

From chen.l.liang at oracle.com  Thu Apr 10 18:16:39 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Thu, 10 Apr 2025 18:16:39 +0000
Subject: java.lang.String hashCode and @Stable ?
In-Reply-To: <500256835.218906672.1744276709174.JavaMail.zimbra@univ-eiffel.fr>
References: <500256835.218906672.1744276709174.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: 

Hi Remi,
I think this is probably due to these fields being added too early - the stable on string byte array is also added lately.

That said, I don't think adding stable on both fields completely resolves the constant folding issues around string hash code. The current code can only constant fold non-zero hash; a zero hash is folded to a read to hash field, which cannot fold further because it's a read of the default value from a stable field.
A solution may be to change hashIsZero to a byte field indicating 3 states - hash unset (0), hash computed to field, hash computed and is zero. This allows the zero hash to constant fold as well at the cost of non-constant hash access performance, as now there are two reads.

Also this reminds me of https://bugs.openjdk.org/browse/JDK-8332249 - maybe Method::hashCode was hot because the string hash code could not fold.

Regards, Chen
________________________________
From: core-libs-dev  on behalf of Remi Forax 
Sent: Thursday, April 10, 2025 4:18 AM
To: core-libs-dev 
Subject: java.lang.String hashCode and @Stable ?

Question,
why String.hash and String.hashIsZero are not declared @Stable ?

regards,
R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From liach at openjdk.org  Thu Apr 10 18:28:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 10 Apr 2025 18:28:50 GMT
Subject: RFR: 8332249: Micro-optimize Method.hashCode [v2]
In-Reply-To: <_cZQqk-UhO06IobPUiqc0kCoRfquUsz2SkrSuo2RDdM=.3da1e381-920c-4be1-9409-d0f6382c82de@github.com>
References: 
 <_cZQqk-UhO06IobPUiqc0kCoRfquUsz2SkrSuo2RDdM=.3da1e381-920c-4be1-9409-d0f6382c82de@github.com>
Message-ID: 

On Mon, 3 Jun 2024 18:00:35 GMT, Sean Gwizdak  wrote:

>> Improve the speed of Method.hashCode by caching the hashcode on first use. I've seen an application where Method.hashCode is a hot path, and this is a fairly simple speedup. The memory overhead is low. 
>> 
>> This addresses issue [JDK-8332249](https://bugs.openjdk.org/browse/JDK-8332249). 
>> 
>> Before:
>> 
>> Benchmark                         Mode  Cnt  Score   Error  Units
>> # Intel Skylake
>> MethodHashCode.benchmarkHashCode  avgt    5  1.843 ? 0.149  ns/op
>> # Arm Neoverse N1
>> MethodHashCode.benchmarkHashCode  avgt    5  2.363 ? 0.091  ns/op
>> 
>> 
>> 
>> After:
>> 
>> 
>> Benchmark                         Mode  Cnt  Score   Error  Units
>> # Intel Skylake
>> MethodHashCode.benchmarkHashCode  avgt    5  1.121 ? 1.189  ns/op
>> # Arm Neoverse N1
>> MethodHashCode.benchmarkHashCode  avgt    5  1.001 ? 0.001  ns/op
>
> Sean Gwizdak 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 trailing whitespace.
>  - Move hashCode benchmark into the newly created MethodBenchmark file
>  - Merge branch 'master' into method-hashcode-JDK-8332249
>  - Remove changes to JavaDoc per guidance.
>  - Fix whitespace issues pointed by the bot
>  - Micro-optimize Method.hashCode

Now in the review of #23972, we noted that `String::hashCode` couldn't constant fold as its hash and hashIsZero fields are missing `@Stable`. If string hash code and xor (see #23089) can constant fold, would this still be necessary?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19433#issuecomment-2794771005

From kvn at openjdk.org  Thu Apr 10 18:29:33 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 10 Apr 2025 18:29:33 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 10 Apr 2025 08:08:32 GMT, Aleksey Shipilev  wrote:

>> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - remove timeout by using waitForReferenceProcessing
>>  - make ill-timed gc in non-concurrent case less likely
>>  - fix test package use
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 357:
> 
>> 355:     @IntrinsicCandidate
>> 356:     public T get() {
>> 357:         return get0();
> 
> I am looking at this now and wondering how current intrinsics matchers work in case of virtual calls. 
> 
> For example, when type information/profile tells us the receiver is generic `Reference`, but in reality it is a `PhantomReference` subclass, would the call to `Reference.get()` -- which is actually `PhantomReference.get()`! -- match accidentally to `Reference.get` intrinsic, and thus enter Access API with `ON_WEAK_REF`? Looks pre-existing, and I would have expected native code to assert, but I also think at least C2 intrinsics do not check the reference type.
> 
> It seems both `clear` and `refersTo` side-step all this by: a) not intrinsifying the virtual methods; b) doing `AS_NO_KEEPALIVE` -- so they are not as exposed. It might be another reason to do this change: to clearly separate `Reference.get` intrinsic and `PhantomReference.get` non-intrinsic...

You need to use intrinsic predicates to add runtime check for receiver. See:
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L167

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2038013798

From alanb at openjdk.org  Thu Apr 10 18:30:36 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Apr 2025 18:30:36 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 18:04:54 GMT, Jan Lahoda  wrote:

>> This is a patch to finalize the module imports feature. Please see:
>> https://bugs.openjdk.org/browse/JDK-8344700
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback: cleanup formatting in ModuleInfo.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23801#pullrequestreview-2757854063

From eirbjo at openjdk.org  Thu Apr 10 18:33:26 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 10 Apr 2025 18:33:26 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 10 Apr 2025 17:23:37 GMT, Raffaello Giulietti  wrote:

> If this is a French name, it's e acute: ?.

Supported by this Wikipedia page listing S.L as an LCMS developer:

https://en.wikipedia.org/wiki/Little_CMS

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2038022994

From eirbjo at openjdk.org  Thu Apr 10 18:45:28 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 10 Apr 2025 18:45:28 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie  wrote:

> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
> 
> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
> 
> Methodology used: 
> 
> I have run four different tools for using different heuristics for determining the encoding of a file:
> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
> * enca (targeted towards obscure code pages)
> * libmagic / `file  --mime-encoding`
> 
> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
> 
> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
> * All files where at least one tool claimed it to be UTF-8
> * All files where at least one tool claimed it to be *not* UTF-8
> 
> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
> 
> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure binary files, but without any telling exten...

src/java.desktop/share/legal/lcms.md line 103:

> 101: Tim Zaman
> 102: Amir Montazery and Open Source Technology Improvement Fund (ostif.org), Google, for fuzzer fundings.
> 103: ```

This introduces an empty trailing line. I see you have removed trailing whitespace elsewhere.

Was this intentional, to avoid the file ending with the three ticks?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2038071768

From jlu at openjdk.org  Thu Apr 10 18:47:53 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 10 Apr 2025 18:47:53 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <0q0gTsqIsYtmzAfNYbBXksUXKdZh2uzQ9yvSETKAP88=.137372e6-d63e-4539-b196-4bd9ef1ddd16@github.com>
References: 
 
 <0q0gTsqIsYtmzAfNYbBXksUXKdZh2uzQ9yvSETKAP88=.137372e6-d63e-4539-b196-4bd9ef1ddd16@github.com>
Message-ID: <9aQcWun5KNgHgELVwkc3478_RtqfhRL1Cxvyn2Yl0Nw=.07ee596f-e738-4796-8d27-14621ed8860c@github.com>

On Thu, 10 Apr 2025 08:44:28 GMT, Eirik Bj?rsn?s  wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace InputStreamReader with BufferedReader
>
> FWIW, I checked out the revision of the commit previous to this change and found the following:
> 
> 
> % git checkout b55e418a077791b39992042411cde97f68dc39fe^ 
> % find src -name "*.properties" | xargs file | grep -v ASCII
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties: 
>   ISO-8859 text
> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties:
>   Unicode text, UTF-8 text, with very long lines (322)
> 
> 
> Which indicates that that this is the only non-ASCII, non-UTF-8 property file. So we may be lucky.

This conversion was performed under the assumption of ASCII set and Unicode escape sequences, which is the format we expect for the translation process for .properties files. That file should have been omitted from this change. Thank you @eirbjo and @magicus for the analysis and checking!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2794828598

From zjx001202 at gmail.com  Thu Apr 10 18:54:57 2025
From: zjx001202 at gmail.com (Glavo)
Date: Fri, 11 Apr 2025 02:54:57 +0800
Subject: java.lang.String hashCode and @Stable ?
In-Reply-To: 
References: <500256835.218906672.1744276709174.JavaMail.zimbra@univ-eiffel.fr>
 
Message-ID: 

Hi Chen,

I think we can choose an arbitrary non-zero number and assign it to the
`hash` field when the calculated hash is 0.

This has two costs:

   1. When the hash is 0, both the hash and hashIsZero fields need to be
   written after the hash is calculated;
   2. When the hash is really just that number, it cannot be constant
   folded.

Considering this allows the empty string hash to be constant folded, I
guess it's worth it.

Glavo

On Fri, Apr 11, 2025 at 2:16?AM Chen Liang  wrote:

> Hi Remi,
> I think this is probably due to these fields being added too early - the
> stable on string byte array is also added lately.
>
> That said, I don't think adding stable on both fields completely resolves
> the constant folding issues around string hash code. The current code can
> only constant fold non-zero hash; a zero hash is folded to a read to hash
> field, which cannot fold further because it's a read of the default value
> from a stable field.
> A solution may be to change hashIsZero to a byte field indicating 3
> states - hash unset (0), hash computed to field, hash computed and is zero.
> This allows the zero hash to constant fold as well at the cost of
> non-constant hash access performance, as now there are two reads.
>
> Also this reminds me of https://bugs.openjdk.org/browse/JDK-8332249 -
> maybe Method::hashCode was hot because the string hash code could not fold.
>
> Regards, Chen
> ------------------------------
> *From:* core-libs-dev  on behalf of Remi
> Forax 
> *Sent:* Thursday, April 10, 2025 4:18 AM
> *To:* core-libs-dev 
> *Subject:* java.lang.String hashCode and @Stable ?
>
> Question,
> why String.hash and String.hashIsZero are not declared @Stable ?
>
> regards,
> R?mi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From eirbjo at openjdk.org  Thu Apr 10 19:09:35 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 10 Apr 2025 19:09:35 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie  wrote:

> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
> 
> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
> 
> Methodology used: 
> 
> I have run four different tools for using different heuristics for determining the encoding of a file:
> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
> * enca (targeted towards obscure code pages)
> * libmagic / `file  --mime-encoding`
> 
> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
> 
> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
> * All files where at least one tool claimed it to be UTF-8
> * All files where at least one tool claimed it to be *not* UTF-8
> 
> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
> 
> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure binary files, but without any telling exten...

LGTM.

There are some whitepace releated changes in this PR which seem okay, but has no mention in either the JBS or PR description.

Perhaps a short mention of this intention in either place would be good for future historians.

(BTW, I enjoyed seeing separate commits for the encoding and BOM changes, makes it easier to verify each!)

-------------

Marked as reviewed by eirbjo (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24566#pullrequestreview-2758055634

From rriggs at openjdk.org  Thu Apr 10 19:22:40 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 10 Apr 2025 19:22:40 GMT
Subject: Integrated: 8353641: Deprecate core library permission classes for
 removal
In-Reply-To: 
References: 
Message-ID: 

On Fri, 4 Apr 2025 12:37:32 GMT, Roger Riggs  wrote:

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

This pull request has now been integrated.

Changeset: af5db513
Author:    Roger Riggs 
URL:       https://git.openjdk.org/jdk/commit/af5db513060db5f89c071f531e6111c69fcd7370
Stats:     54 lines in 17 files changed: 26 ins; 8 del; 20 mod

8353641: Deprecate core library permission classes for removal

Reviewed-by: mullan, iris

-------------

PR: https://git.openjdk.org/jdk/pull/24444

From smarks at openjdk.org  Thu Apr 10 19:37:40 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 10 Apr 2025 19:37:40 GMT
Subject: RFR: 8351740: Clean up some code around initialization of encoding
 properties [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 18:14:52 GMT, Stuart Marks  wrote:

>> Some of the code that creates various encoding properties at JVM initialization time, such as file.encoding and native.encoding, could use some cleaning up. Cleanup is fairly minimal and should be mostly behavior-preserving. Changes include the following:
>> 
>> * In the java_props.h and java_props_md.c files, add documentation and asserts that the sprops.encoding and sprops.sun_jnu_encoding members are always set to non-NULL by the platform-specific code.
>> 
>> * In SystemProps.java, remove a null check that is now extraneous based on the above assertion.
>> 
>> * In SystemProps.java, rearrange logic (with no behavior change) around handling of the "COMPAT" value for the file.encoding property.
>> 
>> * In SystemProps.Raw, rename the platform properties array index from _file_encoding_NDX to _native_encoding_NDX.
>> 
>> * In SystemProps.Raw.cmdProperties(), adjust the HashMap size computation. This should actually avoid resizing of the HashMap (unlike the earlier code).
>> 
>> * Adjust various comments in several places for clarity and correctness.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyrights; change var to String in a couple places.

Need re-review on this after my updates, if anyone gets a chance. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24463#issuecomment-2794961461

From naoto at openjdk.org  Thu Apr 10 19:43:32 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 10 Apr 2025 19:43:32 GMT
Subject: RFR: 8351740: Clean up some code around initialization of encoding
 properties [v3]
In-Reply-To: 
References: 
 
Message-ID: <4OlaMrOfNZApNcQ5FD9r5CWC3ALNx5RwgIwgLwzpnj0=.60ba9ac5-5d0f-44c0-8c69-ffcbb0d5859a@github.com>

On Thu, 10 Apr 2025 18:14:52 GMT, Stuart Marks  wrote:

>> Some of the code that creates various encoding properties at JVM initialization time, such as file.encoding and native.encoding, could use some cleaning up. Cleanup is fairly minimal and should be mostly behavior-preserving. Changes include the following:
>> 
>> * In the java_props.h and java_props_md.c files, add documentation and asserts that the sprops.encoding and sprops.sun_jnu_encoding members are always set to non-NULL by the platform-specific code.
>> 
>> * In SystemProps.java, remove a null check that is now extraneous based on the above assertion.
>> 
>> * In SystemProps.java, rearrange logic (with no behavior change) around handling of the "COMPAT" value for the file.encoding property.
>> 
>> * In SystemProps.Raw, rename the platform properties array index from _file_encoding_NDX to _native_encoding_NDX.
>> 
>> * In SystemProps.Raw.cmdProperties(), adjust the HashMap size computation. This should actually avoid resizing of the HashMap (unlike the earlier code).
>> 
>> * Adjust various comments in several places for clarity and correctness.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyrights; change var to String in a couple places.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24463#pullrequestreview-2758171821

From michaelm at openjdk.org  Thu Apr 10 21:26:21 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 10 Apr 2025 21:26:21 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v5]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  update to minimise code changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/f5501d18..c41146b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=03-04

  Stats: 208 lines in 26 files changed: 16 ins; 61 del; 131 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From ihse at openjdk.org  Thu Apr 10 21:28:31 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 21:28:31 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie  wrote:

> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
> 
> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
> 
> Methodology used: 
> 
> I have run four different tools for using different heuristics for determining the encoding of a file:
> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
> * enca (targeted towards obscure code pages)
> * libmagic / `file  --mime-encoding`
> 
> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
> 
> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
> * All files where at least one tool claimed it to be UTF-8
> * All files where at least one tool claimed it to be *not* UTF-8
> 
> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
> 
> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure binary files, but without any telling exten...

The whitespace changes are my editor removing whitespaces at the end of a line. This is a thing we enforce for many files types, but the check does not yet formally include .txt files. I have been working from time to time with trying to extend the set of files covered by this check, so I have in general not tried to circumvent my editor when it strips trailing whitespaces even for files that we do not yet require no trailing whitespaces in jcheck.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24566#issuecomment-2795201480

From ihse at openjdk.org  Thu Apr 10 21:28:32 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 21:28:32 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: 
References: 
 
Message-ID: <1IvhgoM9LMGg7s2kq_N0V7F1GCh-xFBnauZ9Ajk2Txo=.672329ea-e4c9-437c-a8b7-0502a9fdd414@github.com>

On Thu, 10 Apr 2025 19:06:35 GMT, Eirik Bj?rsn?s  wrote:

> (BTW, I enjoyed seeing separate commits for the encoding and BOM changes, makes it easier to verify each!)

Thanks! I do very much like myself to review PRs that has separate logical commits, so I try to produce such myself. I'm glad to hear it was appreciated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24566#issuecomment-2795203125

From ihse at openjdk.org  Thu Apr 10 21:28:32 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 21:28:32 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 10 Apr 2025 18:30:22 GMT, Eirik Bj?rsn?s  wrote:

>> If this is a French name, it's e acute: ?.
>
>> If this is a French name, it's e acute: ?.
> 
> Supported by this Wikipedia page listing S.L as an LCMS developer:
> 
> https://en.wikipedia.org/wiki/Little_CMS

It's not a mistake in capitalization, it's a mistake for two different characters in two different encodings. (Probably iso-8859-1 mistaken as ansi iirc.)

I verified the developers name at the original file in the LCMS repo.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2038362034

From michaelm at openjdk.org  Thu Apr 10 21:31:31 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 10 Apr 2025 21:31:31 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 21:26:21 GMT, Michael McMahon  wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to minimise code changes

I've just updated the PR with a change that replaces the new methods of the form `throwException()` with the previous pattern of the form `throw new XException`. This reduces the code changes a bit further and is more readable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2795207656

From kvn at openjdk.org  Thu Apr 10 21:42:35 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 10 Apr 2025 21:42:35 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 7 Apr 2025 23:32:05 GMT, Vladimir Ivanov  wrote:

>> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
>> 
>> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
>> 
>> The patch consists of the following parts:
>>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
>> 
>> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
>> 
>> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
>> 
>> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
>> 
>> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
>> 
>> Thanks!
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix windows-aarch64 build failure

Marked as reviewed by kvn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24462#pullrequestreview-2758486176

From kvn at openjdk.org  Thu Apr 10 21:42:37 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 10 Apr 2025 21:42:37 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 7 Apr 2025 23:20:05 GMT, Vladimir Ivanov  wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/CPUFeatures.java line 60:
>> 
>>> 58:     }
>>> 59: 
>>> 60:     public static class X64 {
>> 
>> Should we create `src/jdk.incubator.vector/cpu/` for CPU specific information? As separate refactoring.
>
> To clarify: are you suggesting to move platform-specific classes into a separate package or platform-specific location? 
> 
> It does make sense to separate platform-specific parts into their own classes once amount of code grows over some limit. For now it doesn't look too attractive since amount of code is very small.

ok

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 100:
>> 
>>> 98: 
>>> 99:     /**
>>> 100:      * Naming convention in SVML vector math library.
>> 
>> Does this library has code for all AVX configurations?
>
> Yes, there are 4 configurations (`-XX:UseAVX=[0..3]`) in total covered by SVML library.

Good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2038379482
PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2038379716

From smarks at openjdk.org  Thu Apr 10 21:46:35 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 10 Apr 2025 21:46:35 GMT
Subject: Integrated: 8351740: Clean up some code around initialization of
 encoding properties
In-Reply-To: 
References: 
Message-ID: 

On Fri, 4 Apr 2025 23:42:26 GMT, Stuart Marks  wrote:

> Some of the code that creates various encoding properties at JVM initialization time, such as file.encoding and native.encoding, could use some cleaning up. Cleanup is fairly minimal and should be mostly behavior-preserving. Changes include the following:
> 
> * In the java_props.h and java_props_md.c files, add documentation and asserts that the sprops.encoding and sprops.sun_jnu_encoding members are always set to non-NULL by the platform-specific code.
> 
> * In SystemProps.java, remove a null check that is now extraneous based on the above assertion.
> 
> * In SystemProps.java, rearrange logic (with no behavior change) around handling of the "COMPAT" value for the file.encoding property.
> 
> * In SystemProps.Raw, rename the platform properties array index from _file_encoding_NDX to _native_encoding_NDX.
> 
> * In SystemProps.Raw.cmdProperties(), adjust the HashMap size computation. This should actually avoid resizing of the HashMap (unlike the earlier code).
> 
> * Adjust various comments in several places for clarity and correctness.

This pull request has now been integrated.

Changeset: 83c7d3bb
Author:    Stuart Marks 
URL:       https://git.openjdk.org/jdk/commit/83c7d3bbe860656ee403fa29df6a9e0aae962839
Stats:     56 lines in 5 files changed: 19 ins; 8 del; 29 mod

8351740: Clean up some code around initialization of encoding properties

Reviewed-by: naoto, alanb, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/24463

From asemenyuk at openjdk.org  Thu Apr 10 21:56:39 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 10 Apr 2025 21:56:39 GMT
Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables
 available in *.cfg files [v10]
In-Reply-To: 
References: 
 
 
 <48XUp04EgIXYClNpiBYOVe_42cJAljCARwz1-HWUTYA=.7bdd2f12-5487-43fb-be12-c3185749a738@github.com>
 
Message-ID: 

On Thu, 10 Apr 2025 16:52:15 GMT, Alexey Semenyuk  wrote:

>> I'm guessing a possible fix would be to use 
>> 
>> `${`
>> 
>> or
>> 
>> "`${`"
>> 
>> instead.
>> 
>> Alternatively, we need to tell pandoc to not try and use any encoded TeX math in markdown files.
>
> I filed https://bugs.openjdk.org/browse/JDK-8354320 to fix the warning

Adding backslash character (``) before the dollar character (`"${"` -> `"${"`) suppressed the warning, and the man page looks as expected.

PR https://github.com/openjdk/jdk/pull/24585

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23923#discussion_r2038392825

From asemenyuk at openjdk.org  Thu Apr 10 21:57:40 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 10 Apr 2025 21:57:40 GMT
Subject: RFR: 8354320: Changes to jpackage.md cause pandoc warning
Message-ID: 

Escape the dollar sign.

-------------

Commit messages:
 - 8354320: Changes to jpackage.md cause pandoc warning

Changes: https://git.openjdk.org/jdk/pull/24585/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24585&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354320
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24585.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24585/head:pull/24585

PR: https://git.openjdk.org/jdk/pull/24585

From asemenyuk at openjdk.org  Thu Apr 10 21:57:40 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 10 Apr 2025 21:57:40 GMT
Subject: RFR: 8354320: Changes to jpackage.md cause pandoc warning
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Apr 2025 21:50:10 GMT, Alexey Semenyuk  wrote:

> Escape the dollar sign.

@sashamatveev PTAL

@magicus PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24585#issuecomment-2795242824
PR Comment: https://git.openjdk.org/jdk/pull/24585#issuecomment-2795249016

From rriggs at openjdk.org  Thu Apr 10 22:10:43 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 10 Apr 2025 22:10:43 GMT
Subject: RFR: 8354335: No longer deprecate wrapper class constructors for
 removal
Message-ID: 

Remove forRemoval = true from @Deprecated annotation of Boolean, Byte, Character, Double, Float, Integer, Long, Short.
And add `SuppressWarnings("deprecation") `where needed; and remove `SuppressWarnings("removal")`

-------------

Commit messages:
 - 8354335: No longer deprecate wrapper class constructors for removal

Changes: https://git.openjdk.org/jdk/pull/24586/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24586&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354335
  Stats: 23 lines in 9 files changed: 0 ins; 0 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/24586.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24586/head:pull/24586

PR: https://git.openjdk.org/jdk/pull/24586

From bchristi at openjdk.org  Thu Apr 10 22:24:04 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 10 Apr 2025 22:24:04 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v4]
In-Reply-To: 
References: 
Message-ID: 

> Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead to intermittent test failures ([JDK-8298783](https://bugs.openjdk.org/browse/JDK-8298783)  is a recent example).
> 
> A better mechanism already exists in the private `Reference.waitForReferenceProcessing()` method. This PR makes `waitForReferenceProcessing()` available to tests via the `WhiteBox` and `ForceGC` test libraries.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  Separate method to setup Method, per Kim; also simplify exception handling

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24527/files
  - new: https://git.openjdk.org/jdk/pull/24527/files/4b838e7a..8aa0595a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24527&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24527&range=02-03

  Stats: 34 lines in 1 file changed: 25 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/24527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24527/head:pull/24527

PR: https://git.openjdk.org/jdk/pull/24527

From bchristi at openjdk.org  Thu Apr 10 22:24:05 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 10 Apr 2025 22:24:05 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 10 Apr 2025 05:51:04 GMT, Kim Barrett  wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reflection improvements
>
> test/lib/jdk/test/whitebox/WhiteBox.java line 570:
> 
>> 568:    * This method should usually be called after a call to WhiteBox.fullGC().
>> 569:    */
>> 570:   public static void waitForReferenceProcessing() {
> 
> Reference::waitForReferenceProcessing returns boolean.  This should too.

Agreed.

> test/lib/jdk/test/whitebox/WhiteBox.java line 570:
> 
>> 568:    * This method should usually be called after a call to WhiteBox.fullGC().
>> 569:    */
>> 570:   public static void waitForReferenceProcessing() {
> 
> Reference::waitForReferenceProcessing throws InterruptedException.  Probably this should be similarly
> declared.

I disagree. IMO, for a test library, it's an unnecessary burden to make callers catch a checked exception.

> test/lib/jdk/test/whitebox/WhiteBox.java line 570:
> 
>> 568:    * This method should usually be called after a call to WhiteBox.fullGC().
>> 569:    */
>> 570:   public static void waitForReferenceProcessing() {
> 
> WhiteBox functions are nearly all ordinary member functions, not static.

I saw that, but `Reference.waitForReferenceProcessing()` is itself static, and doesn't need any context from `WhiteBox`, so I made it static.
But if `waitForReferenceProcessing()` is only expected to be called following `fullGC()`, a WB instance will be needed anyway.

> test/lib/jdk/test/whitebox/WhiteBox.java line 574:
> 
>> 572:       Method wfrp = Reference.class.getDeclaredMethod("waitForReferenceProcessing");
>> 573:       wfrp.setAccessible(true);
>> 574:       wfrp.invoke(null, new Object[0]);
> 
> Don't need an empty argument vector. Sufficient is `wfrp.invoke(null);`.  I found the documentation
> a bit confusing, as it says "the supplied args array may be ... or null."

Thanks. (I thought I tried that, but I guess not...)

> test/lib/jdk/test/whitebox/WhiteBox.java line 577:
> 
>> 575:     } catch (IllegalAccessException iae) {
>> 576:       throw new RuntimeException("Need to add @modules java.base/java.lang.ref:open?",
>> 577:               iae);
> 
> This isn't a useful message, as we won't get here in this case.  Instead of `invoke` failing with this exception,
> the earlier `setAccessible` will have failed with `InaccessibleObjectException`.

Thanks. The new version will include the message in the case that the @modules tag seems to be missing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2038425087
PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2038428891
PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2038432164
PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2038425699
PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2038424768

From bchristi at openjdk.org  Thu Apr 10 22:30:25 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 10 Apr 2025 22:30:25 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <2Q30plD4M2u02IC25Ek8gMqnl8ED3LpSCImjDEhKySQ=.522ce043-4b74-4b7b-98aa-40a02c81f24b@github.com>

On Thu, 10 Apr 2025 06:08:37 GMT, Kim Barrett  wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reflection improvements
>
> test/lib/jdk/test/whitebox/WhiteBox.java line 578:
> 
>> 576:       throw new RuntimeException("Need to add @modules java.base/java.lang.ref:open?",
>> 577:               iae);
>> 578:     } catch (NoSuchMethodException | InvocationTargetException e) {
> 
> I think for InvocationTargetException the appropriate thing to do is to rethrow the cause, which will
> require dispatching on its dynamic type in order to cast to an appropriate static type.  The only checked
> exception is InterruptedException.  But it could also be RuntimeException or Error.

I simplified the exception handling.
With the default platform and jtreg behavior, stack traces include "caused by" for the original exception. So I don't see much value in extracting the cause ourselves

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2038440255

From bchristi at openjdk.org  Thu Apr 10 22:33:26 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 10 Apr 2025 22:33:26 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 10 Apr 2025 05:33:18 GMT, Kim Barrett  wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reflection improvements
>
> test/lib/jdk/test/whitebox/WhiteBox.java line 572:
> 
>> 570:   public static void waitForReferenceProcessing() {
>> 571:     try {
>> 572:       Method wfrp = Reference.class.getDeclaredMethod("waitForReferenceProcessing");
> 
> Why was the caching of the method removed in the latest commit?
> 
> It seems like it might be cleaner to split this into a helper that gets the Method object, with a catch clause
> for NoSuchMethodException.  Such a helper would also be a place to verify/assert various properties of
> the found method, such as empty parameter list, return type is boolean, one declared exception type
> (InterruptedException), all of which can then be assumed by the invocation.

Thanks for posting your version; I used it as the basis for my latest patch.
I left the `assert`s, but would also be OK with throwing an exception if anything was not as expected.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2038442479

From liach at openjdk.org  Thu Apr 10 23:43:23 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 10 Apr 2025 23:43:23 GMT
Subject: RFR: 8354335: No longer deprecate wrapper class constructors for
 removal
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Apr 2025 22:05:04 GMT, Roger Riggs  wrote:

> Remove forRemoval = true from @Deprecated annotation of Boolean, Byte, Character, Double, Float, Integer, Long, Short.
> And add `SuppressWarnings("deprecation") `where needed; and remove `SuppressWarnings("removal")`

The wrapper classes and MemberName changes look good.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24586#pullrequestreview-2758769422

From liach at openjdk.org  Fri Apr 11 00:21:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Apr 2025 00:21:38 GMT
Subject: RFR: 8347472: Correct Attribute traversal and writing for Code
 attributes
In-Reply-To: 
References: 
Message-ID: 

On Fri, 7 Feb 2025 19:25:04 GMT, Chen Liang  wrote:

> Make UnknownAttribute and CustomAttribute delivered in code traversal, and make sure stack maps update the label references after a code transform when it is reused. Other code-bound attributes are not updated as they cannot be supplied to a CodeBuilder.
> 
> Tested the 2 cases in the new AttributesInCodeTest fails on earlier JDKs.
> 
> Testing: JDK tier 1-3 ongoing

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23521#issuecomment-2795475481

From liach at openjdk.org  Fri Apr 11 00:21:39 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Apr 2025 00:21:39 GMT
Subject: Integrated: 8347472: Correct Attribute traversal and writing for Code
 attributes
In-Reply-To: 
References: 
Message-ID: 

On Fri, 7 Feb 2025 19:25:04 GMT, Chen Liang  wrote:

> Make UnknownAttribute and CustomAttribute delivered in code traversal, and make sure stack maps update the label references after a code transform when it is reused. Other code-bound attributes are not updated as they cannot be supplied to a CodeBuilder.
> 
> Tested the 2 cases in the new AttributesInCodeTest fails on earlier JDKs.
> 
> Testing: JDK tier 1-3 ongoing

This pull request has now been integrated.

Changeset: 7bb8b176
Author:    Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/7bb8b1768f0992d066f33f340be42dbd7c21dcc9
Stats:     216 lines in 10 files changed: 198 ins; 6 del; 12 mod

8347472: Correct Attribute traversal and writing for Code attributes

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/23521

From smarks at openjdk.org  Fri Apr 11 02:28:35 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 11 Apr 2025 02:28:35 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 10 Apr 2025 22:18:20 GMT, Brent Christian  wrote:

>> test/lib/jdk/test/whitebox/WhiteBox.java line 570:
>> 
>>> 568:    * This method should usually be called after a call to WhiteBox.fullGC().
>>> 569:    */
>>> 570:   public static void waitForReferenceProcessing() {
>> 
>> Reference::waitForReferenceProcessing throws InterruptedException.  Probably this should be similarly
>> declared.
>
> I disagree. IMO, for a test library, it's an unnecessary burden to make callers catch a checked exception.

Hm. In general, if something blocks interruptibly, it should be declared to throw InterruptedException instead of catching and rethrowing something of another exception type. We should look at the use sites to be sure, but it's generally not an inconvenience for tests to deal with checked exceptions; it's perfectly acceptable for them to declare `throws InterruptedException` or even `throws Exception` and let the framework handle the exception if the test itself doesn't want to.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2038705048

From smarks at openjdk.org  Fri Apr 11 02:28:37 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 11 Apr 2025 02:28:37 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 22:24:04 GMT, Brent Christian  wrote:

>> Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead to intermittent test failures ([JDK-8298783](https://bugs.openjdk.org/browse/JDK-8298783)  is a recent example).
>> 
>> A better mechanism already exists in the private `Reference.waitForReferenceProcessing()` method. This PR makes `waitForReferenceProcessing()` available to tests via the `WhiteBox` and `ForceGC` test libraries.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Separate method to setup Method, per Kim; also simplify exception handling

test/lib/jdk/test/whitebox/WhiteBox.java line 573:

> 571:         wfrp.setAccessible(true);
> 572:         assert wfrp.getReturnType() == Boolean.class;
> 573:         assert wfrp.getParameterCount() == 0;

I don't think this is necessary, as the absence of an array argument to `getDeclaredMethod` should find only methods with zero args.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2038705670

From serb at openjdk.org  Fri Apr 11 03:37:29 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 11 Apr 2025 03:37:29 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie  wrote:

> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
> 
> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
> 
> Methodology used: 
> 
> I have run four different tools for using different heuristics for determining the encoding of a file:
> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
> * enca (targeted towards obscure code pages)
> * libmagic / `file  --mime-encoding`
> 
> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
> 
> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
> * All files where at least one tool claimed it to be UTF-8
> * All files where at least one tool claimed it to be *not* UTF-8
> 
> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
> 
> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure binary files, but without any telling exten...

src/demo/share/java2d/J2DBench/resources/textdata/arabic.ut8.txt line 11:

> 9: ???????? ???????????? ?????????????? "??????????????" ???????? ?????????? ?????? ???????? ???? ???????? ???????????? ?????????????????? ???????? ?????? ?????????? ???? ?????? ?????????????? ???? ?????????????? ??????????????????. ?????? ?????? ???????? ???????????? "??????????????" ???????? ???????? ???????? ???????????????? ???????????? ???????????????? ?????? ?????????????? ?????? ?????????? ????.????.????. (IBM)?? ???????? (APPLE)?? ???????????????????? ?????????????? (Hewlett-Packard) ?? ???????????????????? (Microsoft)?? ???????????????? (Oracle) ?? ???? (Sun) ????????????. ?????? ???? ?????????????????? ?????????????????? ?????????????? (?????? ?????? ?????????????? "????????" "JAVA" ???????? "?????? ???? ????" "XML" ???????? ???????????? ???????????? ??????????????????) ?????????? ?????????????? "??????????????". ?????????? ?????? ?????? ?? ?????? "??????????????" ???? ???????????????????? ???????????????? ???????????? ???????????????? ???????????????????? ???????? ??????
 ????  (ISO 10646) .
> 10: 
> 11: ???? ???????? ???????????? "??????????????" ?????????????? ?????????????? ???????? ?????????????? ?????????????? ?????????? ???? ?????? ???????????????????? ?????????????? ???? ?????????? ?????????????????? ?????????? ???????????? ???? ????????????. ?????? ?????????????? "??????????????" ???? ???????? ?????????????????? ?????????? ?????? ?????????? ???????? ???????????? ???? ?????????????? ?????????????????? ?????????????????? ?????????????? ??????????????. ?????? ???? ?????????????? "??????????????" ???????????????? ?????????????? ???? ?????????? ???????????????? ?????? ???????????? ?????????????????? ?????? ???? ?????? ???? ?????????????? ???? ???????????????? ???????? ?????? ???? ???????? ???? ???????????? ?????????? ?????????? ?????? ???????????? ???????????? ?????????????? ???? ?????????? ???? ??????????. ?????????????? ?????? ?????????????? "??????????????" ?????????? ???????????????? ???? ???????????????? ?????? ?????????????? ???????????????? ???????????????? ?????? ???
 ? ?????????? ?????????????????? ???????? ?????????? ?????????????? ?????????????? ?????????????? ???????????????? ???????????? ???????? ?????? ???? ???????????? ?????? ????????????????.

Looks like most of the changes in java2d/* are related to spaces at the end of the line?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2038746193

From kbarrett at openjdk.org  Fri Apr 11 05:11:29 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 11 Apr 2025 05:11:29 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 22:24:04 GMT, Brent Christian  wrote:

>> Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead to intermittent test failures ([JDK-8298783](https://bugs.openjdk.org/browse/JDK-8298783)  is a recent example).
>> 
>> A better mechanism already exists in the private `Reference.waitForReferenceProcessing()` method. This PR makes `waitForReferenceProcessing()` available to tests via the `WhiteBox` and `ForceGC` test libraries.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Separate method to setup Method, per Kim; also simplify exception handling

Marked as reviewed by kbarrett (Reviewer).

test/lib/jdk/test/whitebox/WhiteBox.java line 598:

> 596:     try {
> 597:       Method wfrp = getWaitForReferenceProcessingMethod();
> 598:       return (Boolean) wfrp.invoke(null);

I didn't know there was an implicit conversion from Boolean to boolean.  Nice!

test/lib/jdk/test/whitebox/WhiteBox.java line 603:

> 601:       throw e;
> 602:     } catch (Throwable t) {
> 603:       throw new RuntimeException(t);

The more complicated exception handling in my prototype was to make this
wrapper function behave like the wrapped function. But maybe that's
over-engineering? Although it seems wrong to me to wrap an Error in a
RuntimeException. But implementations of `invoke` are already doing the
similar thing of wrapping an Error in an InvocationTargetException (which this
code just further wraps). That also seems wrong to me, but seems to be
long-standing behavior.  Oh well.  I guess this is okay.  Certainly it's simpler
for test usage.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24527#pullrequestreview-2759155279
PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2038806687
PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2038807296

From duke at openjdk.org  Fri Apr 11 06:36:45 2025
From: duke at openjdk.org (Markus KARG)
Date: Fri, 11 Apr 2025 06:36:45 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <4U3TP4zVn6Bg39f6rLOCDT97Zfj33DEMrJm2seoatN4=.155d1292-2a03-4b5b-ad7e-62adf9bd2be7@github.com>
References: 
 
 <4U3TP4zVn6Bg39f6rLOCDT97Zfj33DEMrJm2seoatN4=.155d1292-2a03-4b5b-ad7e-62adf9bd2be7@github.com>
Message-ID: <5TyyklVSyjd6_Cxsbea5bqiPqKDHG6qb3Fxe-O9KAdQ=.d6292b16-d554-4ec4-babd-f8e0c18037ae@github.com>

On Tue, 8 Apr 2025 18:12:03 GMT, Chen Liang  wrote:

> Should we ask hotspot compiler engineers for inputs on how useful this API is for allowing batch/vectorized copy and eliminating overheads of defensive copy array allocation?

I have no strong feelings about that.

As it looks like we reached concensus on the proposed change, I have now copied the spec into the CSR and set it into the proposed state. Kindly asking for your reviews of the CSR, so it can rather soon proceed into the provisional state.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2795968057

From fyang at openjdk.org  Fri Apr 11 07:06:38 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 11 Apr 2025 07:06:38 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L [v7]
In-Reply-To: <317DYBGa3NAUfowhgTFeq8Crezuz-mV9io6nW1IXccc=.d37f6b47-ac06-4234-9162-8aca891630d7@github.com>
References: 
 <317DYBGa3NAUfowhgTFeq8Crezuz-mV9io6nW1IXccc=.d37f6b47-ac06-4234-9162-8aca891630d7@github.com>
Message-ID: <4cfNjUGKQ4o4DrUBM_-JqcAiRlXp06y-NuipEo9cjTU=.65bdc5e4-4d5c-44ae-9eff-279b58a4b336@github.com>

On Thu, 10 Apr 2025 12:08:29 GMT, Hamlin Li  wrote:

>> Hi,
>> Can you help to review this patch?
>> On riscv, CMoveI/L already were implemented, but there are some gap:
>> 1. CMoveI/L does not support comparison with float/double, corresponding tests are not turn on either.
>> 2. Some optimization of C2 is not turned on, e.g. `Phi -> CMove -> min_max`.
>> 3. lack of some corresponding performance tests.
>> 
>> Also there are some issue with current Zicond:
>> 1. UseZicond is turned on automatically by hwprobe, but jmh tests show that it's not always bring benefit, in some situation it even brings regression, the reason is the generated code by Zicond is much larger than branch version, in particular when it's in a loop and unrolled.
>> 
>> This patch on riscv is to:
>> 1. add CMoveI/L comparing float/double, and corresponding tests,
>> 2. enable more C2 optimization,
>> 3. add more benchmark tests,
>> 4. turn off UseZicond by default.
>> 
>> Thanks!
>> 
>> ## Performance
>> 
>> ### MinMax
>> test data
>> 
>> Benchmark | Mode | Cnt | Score - master | Score - master+UseZbb | Score - -master+UseZicond | Score - master+UseZicond+UseZbb | Score - cmovei | Score - cmovei+UseZbb | Score - cmovei+UseZicond | Score - cmovei+UseZicond+UseZbb | Error | Units | Opt (master/cmovei)
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> o.o.b.vm.compiler.IfMinMax.testReductionInt | avgt | 40 | 17152.075 | 17216.592 | 17272.493 | 17296.89 | 17127.844 | 17036.605 | 17299.333 | 17250.566 | 73.179 | ns/op | 1.001
>> o.o.b.vm.compiler.IfMinMax.testReductionLong | avgt | 40 | 19770.828 | 19967.578 | 20268.905 | 20166.165 | 20065.552 | 20059.095 | 20161.914 | 20151.295 | 131.428 | ns/op | 0.985
>> o.o.b.vm.compiler.IfMinMax.testSingleInt | avgt | 40 | 114.734 | 114.402 | 114.887 | 114.384 | 114.4 | 110.631 | 112.162 | 110.915 | 0.333 | ns/op | 1.003
>> o.o.b.vm.compiler.IfMinMax.testSingleLong | avgt | 40 | 121.53 | 121.711 | 120.91 | 121.665 | 121.309 | 120.57 | 118.639 | 119.373 | 0.451 | ns/op | 1.002
>> o.o.b.vm.compiler.IfMinMax.testVectorInt | avgt | 40 | 60130.165 | 60062.303 | 61839.776 | 61895.194 | 15887.398 | 15924.502 | 15874.835 | 15667.936 | 101.94 | ns/op | 3.785
>> o.o.b.vm.c...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   enable more test

Thanks for the updates. Several minor comments remain :-)

src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 2173:

> 2171:       break;
> 2172:     case BoolTest::ge:
> 2173:       cmov_cmp_fp_ge(op1, op2, dst, src, is_single);

This calls `cmov_cmp_fp_ge` and `cmov_cmp_fp_gt` assembler routines for `BoolTest::ge` and `BoolTest::gt` respectively, but these two assembler routines are NOT implemented in file macroAssembler_riscv.cpp. That seems a bit confusing to me. How about making these two cases unreachable in this function? Or simply implement these two assembler routines?

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1361:

> 1359: //   java code      :  cmp1 > cmp2 ? dst : src
> 1360: //   transformed to :  CMove dst, (cmp1 le cmp2), dst, src
> 1361: // So, cmov_le_fp is invoked instead this method.

I think you mean `cmov_cmp_fp_le` instead of `cmov_le_fp` in this code comment?

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1396:

> 1394: // Clarification:
> 1395: //   java code      :  cmp2 <= cmp1 ? dst : src
> 1396: //   transformed to :  CMove dst, (cmp1 lt cmp2), dst, src

Does this code comment need update? Seems it's the same as the one for `cmov_cmp_fp_lt`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24490#pullrequestreview-2759089118
PR Review Comment: https://git.openjdk.org/jdk/pull/24490#discussion_r2038766122
PR Review Comment: https://git.openjdk.org/jdk/pull/24490#discussion_r2038762371
PR Review Comment: https://git.openjdk.org/jdk/pull/24490#discussion_r2038763750

From mbaesken at openjdk.org  Fri Apr 11 07:11:19 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 11 Apr 2025 07:11:19 GMT
Subject: RFR: 8354189: Remove JLI_ReportErrorMessageSys on Windows [v2]
In-Reply-To: 
References: 
Message-ID: 

> JLI_ReportErrorMessageSys is not used any more on Windows, so we can remove it and make it UNIX-only (there a still a few remaining usages).

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust COPYRIGHT years

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24563/files
  - new: https://git.openjdk.org/jdk/pull/24563/files/1e46a30e..42ad8727

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24563&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24563&range=00-01

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24563.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24563/head:pull/24563

PR: https://git.openjdk.org/jdk/pull/24563

From mbaesken at openjdk.org  Fri Apr 11 07:11:20 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 11 Apr 2025 07:11:20 GMT
Subject: RFR: 8354189: Remove JLI_ReportErrorMessageSys on Windows [v2]
In-Reply-To: <_h-nvBgAg_d_PeQVQYIjpqchqHuWRoxinf3P2MRiSDs=.5cc51ba6-3123-401b-bbe4-c8108b5a57c0@github.com>
References: 
 <_h-nvBgAg_d_PeQVQYIjpqchqHuWRoxinf3P2MRiSDs=.5cc51ba6-3123-401b-bbe4-c8108b5a57c0@github.com>
Message-ID: 

On Thu, 10 Apr 2025 15:42:06 GMT, Alan Bateman  wrote:

> I think this looks okay, can you update the copyright header dates before you integrate.

Sure, I adjusted the copyright header dates.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24563#issuecomment-2796041681

From clanger at openjdk.org  Fri Apr 11 07:27:27 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 11 Apr 2025 07:27:27 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 9 Apr 2025 16:10:20 GMT, Severin Gehwolf  wrote:

>> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
>> 
>> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
>> 
>> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
>> 2. For those files the hash sum checks are skipped.
>> 
>> **Testing**
>> 
>> - [x] GHA
>> - [x] `jdk/tools/jlink` jtreg tests (also on [GHA](https://github.com/jerboaa/jdk/actions/runs/14376644254))
>> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use *.conf for upgrade files

Marked as reviewed by clanger (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24388#pullrequestreview-2759397284

From clanger at openjdk.org  Fri Apr 11 07:27:29 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 11 Apr 2025 07:27:29 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sat, 5 Apr 2025 04:49:03 GMT, Christoph Langer  wrote:

>> Severin Gehwolf 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:
>> 
>>  - Reboot upgradeable files approach
>>  - Revert "8353185: Introduce the concept of upgradeable files in context of JEP 493"
>>    
>>    This reverts commit bfbfbcb8212ed0f9825549b02b4b52e930c379a7.
>>  - Merge branch 'master' into jdk-8353185-upgradable-files-jep493
>>  - 8353185: Introduce the concept of upgradeable files in context of JEP 493
>
> Just a few fly-by findings, no full review.
> 
> I see that you're actively on the upgradeable files. What about #24190? (@AlanBateman, what are your thoughts, how could we progress there?)

> @RealCLanger Are you OK with the latest patch (as far as your comments are concerned)?

Yes, looks good. ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2796074272

From alanb at openjdk.org  Fri Apr 11 07:35:24 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 11 Apr 2025 07:35:24 GMT
Subject: RFR: 8354189: Remove JLI_ReportErrorMessageSys on Windows [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 07:11:19 GMT, Matthias Baesken  wrote:

>> JLI_ReportErrorMessageSys is not used any more on Windows, so we can remove it and make it UNIX-only (there a still a few remaining usages).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust COPYRIGHT years

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24563#pullrequestreview-2759414858

From alanb at openjdk.org  Fri Apr 11 07:40:25 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 11 Apr 2025 07:40:25 GMT
Subject: RFR: 8354320: Changes to jpackage.md cause pandoc warning
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Apr 2025 21:50:10 GMT, Alexey Semenyuk  wrote:

> Escape the dollar sign.

Thanks for jumping on this.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24585#pullrequestreview-2759425326

From shade at openjdk.org  Fri Apr 11 08:05:32 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Apr 2025 08:05:32 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 10 Apr 2025 18:26:39 GMT, Vladimir Kozlov  wrote:

>> src/java.base/share/classes/java/lang/ref/Reference.java line 357:
>> 
>>> 355:     @IntrinsicCandidate
>>> 356:     public T get() {
>>> 357:         return get0();
>> 
>> I am looking at this now and wondering how current intrinsics matchers work in case of virtual calls. 
>> 
>> For example, when type information/profile tells us the receiver is generic `Reference`, but in reality it is a `PhantomReference` subclass, would the call to `Reference.get()` -- which is actually `PhantomReference.get()`! -- match accidentally to `Reference.get` intrinsic, and thus enter Access API with `ON_WEAK_REF`? Looks pre-existing, and I would have expected native code to assert, but I also think at least C2 intrinsics do not check the reference type.
>> 
>> It seems both `clear` and `refersTo` side-step all this by: a) not intrinsifying the virtual methods; b) doing `AS_NO_KEEPALIVE` -- so they are not as exposed. It might be another reason to do this change: to clearly separate `Reference.get` intrinsic and `PhantomReference.get` non-intrinsic...
>
> You need to use intrinsic predicates to add runtime check for receiver. See:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L167

I think it would be "easier" to shift `@IntrinsicCandidate` to a private `Reference.getImpl` method, and intrinsify that instead. Pretty much like current `clear` and `refersTo` are doing it now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2039019037

From alanb at openjdk.org  Fri Apr 11 08:14:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 11 Apr 2025 08:14:52 GMT
Subject: RFR: 8342486: Implement JEP draft: Structured Concurrency (Fifth
 Preview) [v7]
In-Reply-To: 
References: 
Message-ID: 

> Changes for [JEP draft: Structured Concurrency (Fifth Preview)](https://openjdk.org/jeps/8340343). The JEP isn't on the technical roadmap yet. The proposal is to re-preview the API with some changes, specifically:
> 
> - A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor.  Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close.
> - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner.
> - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions.
> - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function.
> - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method.
>  
> The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Sync up from loom repo
 - Merge branch 'master' into JDK-8342486
 - Sync up from loom repo
 - Merge branch 'master' into JDK-8342486
 - Merge branch 'master' into JDK-8342486
 - Fix link
 - Merge branch 'master' into JDK-8342486
 - Sync up impl/tests form loom repo
 - Merge branch 'master' into JDK-8342486
 - Pull latest API docs + impl from loom repo
 - ... and 3 more: https://git.openjdk.org/jdk/compare/d8bed693...0ca374ed

-------------

Changes: https://git.openjdk.org/jdk/pull/21934/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21934&range=06
  Stats: 4082 lines in 14 files changed: 1862 ins; 1447 del; 773 mod
  Patch: https://git.openjdk.org/jdk/pull/21934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21934/head:pull/21934

PR: https://git.openjdk.org/jdk/pull/21934

From kbarrett at openjdk.org  Fri Apr 11 08:17:47 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 11 Apr 2025 08:17:47 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 2 Apr 2025 18:38:17 GMT, Kim Barrett  wrote:

>> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - remove timeout by using waitForReferenceProcessing
>>  - make ill-timed gc in non-concurrent case less likely
>>  - fix test package use
>
> test/hotspot/jtreg/gc/TestNativeReferenceGet.java line 137:
> 
>> 135:             }
>> 136:             checkQueue();       // One last check after refproc complete.
>> 137:         } catch (InterruptedException e) {
> 
> Rather than using Reference.remove with a timeout, I've changed this to use waitForReferenceProcessing.
> That removes false passes (from reference processing being slow to deliver) and also removes the delay
> until timeout for the passing case.

https://github.com/openjdk/jdk/pull/24527 is proposing a different way to access
`waitForReferenceProcessing`.  I'll wait for that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2039040491

From forax at univ-mlv.fr  Fri Apr 11 08:53:37 2025
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 11 Apr 2025 10:53:37 +0200 (CEST)
Subject: java.lang.String hashCode and @Stable ?
In-Reply-To: 
References: <500256835.218906672.1744276709174.JavaMail.zimbra@univ-eiffel.fr>
 
 
Message-ID: <516257952.220171502.1744361617764.JavaMail.zimbra@univ-eiffel.fr>

> From: "Glavo" 
> To: "Chen Liang" 
> Cc: "Remi Forax" , "core-libs-dev"
> 
> Sent: Thursday, April 10, 2025 8:54:57 PM
> Subject: Re: java.lang.String hashCode and @Stable ?

> Hi Chen,
> I think we can choose an arbitrary non-zero number and assign it to the `hash`
> field when the calculated hash is 0.

Usually yes, for String no. 
String.hashCode() computation is fully specified in the javadoc so changing the returned value is not a backward compatible change. 

When you compile a switch(String) the compiler computes the hashCode of the cases and switch on those values, so those hashCode values are inserted in the bytecode. 
If you change the algorithm of String.hashCode(), the runtime value and the compiled value will not be the same. 

regards, 
R?mi 

> Glavo

> On Fri, Apr 11, 2025 at 2:16 AM Chen Liang < [ mailto:chen.l.liang at oracle.com |
> chen.l.liang at oracle.com ] > wrote:

>> Hi Remi,
>> I think this is probably due to these fields being added too early - the stable
>> on string byte array is also added lately.

>> That said, I don't think adding stable on both fields completely resolves the
>> constant folding issues around string hash code. The current code can only
>> constant fold non-zero hash; a zero hash is folded to a read to hash field,
>> which cannot fold further because it's a read of the default value from a
>> stable field.
>> A solution may be to change hashIsZero to a byte field indicating 3 states -
>> hash unset (0), hash computed to field, hash computed and is zero. This allows
>> the zero hash to constant fold as well at the cost of non-constant hash access
>> performance, as now there are two reads.

>> Also this reminds me of [ https://bugs.openjdk.org/browse/JDK-8332249 |
>> https://bugs.openjdk.org/browse/JDK-8332249 ] - maybe Method::hashCode was hot
>> because the string hash code could not fold.

>> Regards, Chen

>> From: core-libs-dev < [ mailto:core-libs-dev-retn at openjdk.org |
>> core-libs-dev-retn at openjdk.org ] > on behalf of Remi Forax < [
>> mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >
>> Sent: Thursday, April 10, 2025 4:18 AM
>> To: core-libs-dev < [ mailto:core-libs-dev at openjdk.java.net |
>> core-libs-dev at openjdk.java.net ] >
>> Subject: java.lang.String hashCode and @Stable ?
>> Question,
>> why String.hash and String.hashIsZero are not declared @Stable ?

>> regards,
>> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From shade at openjdk.org  Fri Apr 11 08:54:30 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Apr 2025 08:54:30 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v4]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <-oOK2Dh2vnn9Qc5MBRiKoeauVFVPPV_9fKMqAQwjFfY=.b20b09d9-a268-4ca9-9362-7045c6a3afce@github.com>

On Fri, 11 Apr 2025 08:03:07 GMT, Aleksey Shipilev  wrote:

>> You need to use intrinsic predicates to add runtime check for receiver. See:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L167
>
> I think it would be "easier" to shift `@IntrinsicCandidate` to a private `Reference.getImpl/get0` pair of methods, and intrinsify one of those instead. Pretty much like current `clear` and `refersTo` are doing it now. And it would be in line with what Kim is doing in this PR anyway.

On a second thought, I think we should do this shift before this PR, so that it is cleanly backportable. This bug messes with concurrent GC invariants, so it would be nice to fix it in current LTSes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2039108578

From forax at univ-mlv.fr  Fri Apr 11 09:04:26 2025
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 11 Apr 2025 11:04:26 +0200 (CEST)
Subject: java.lang.String hashCode and @Stable ?
In-Reply-To: 
References: <500256835.218906672.1744276709174.JavaMail.zimbra@univ-eiffel.fr>
 
Message-ID: <920421036.220248445.1744362266698.JavaMail.zimbra@univ-eiffel.fr>

> From: "Chen Liang" 
> To: "Remi Forax" , "core-libs-dev"
> 
> Sent: Thursday, April 10, 2025 8:16:39 PM
> Subject: Re: java.lang.String hashCode and @Stable ?

> Hi Remi,
> I think this is probably due to these fields being added too early - the stable
> on string byte array is also added lately.

> That said, I don't think adding stable on both fields completely resolves the
> constant folding issues around string hash code. The current code can only
> constant fold non-zero hash; a zero hash is folded to a read to hash field,
> which cannot fold further because it's a read of the default value from a
> stable field.
> A solution may be to change hashIsZero to a byte field indicating 3 states -
> hash unset (0), hash computed to field, hash computed and is zero. This allows
> the zero hash to constant fold as well at the cost of non-constant hash access
> performance, as now there are two reads.

yes, 
and obviously, it has to be done without introducing a perf regression if the String is not constant folded. 

I think it would be nice to try that as a follow-up of JDK-8354300. 

> Also this reminds me of [ https://bugs.openjdk.org/browse/JDK-8332249 |
> https://bugs.openjdk.org/browse/JDK-8332249 ] - maybe Method::hashCode was hot
> because the string hash code could not fold.

Usually in framework like Spring, Method are cached either by the framework or by java.lang.Class own cache so the Method itself is rarely a constant. 

> Regards, Chen

regards, 
R?mi 

> From: core-libs-dev  on behalf of Remi Forax
> 
> Sent: Thursday, April 10, 2025 4:18 AM
> To: core-libs-dev 
> Subject: java.lang.String hashCode and @Stable ?
> Question,
> why String.hash and String.hashIsZero are not declared @Stable ?

> regards,
> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kbarrett at openjdk.org  Fri Apr 11 09:11:34 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 11 Apr 2025 09:11:34 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v4]
In-Reply-To: <-oOK2Dh2vnn9Qc5MBRiKoeauVFVPPV_9fKMqAQwjFfY=.b20b09d9-a268-4ca9-9362-7045c6a3afce@github.com>
References: 
 
 
 
 
 <-oOK2Dh2vnn9Qc5MBRiKoeauVFVPPV_9fKMqAQwjFfY=.b20b09d9-a268-4ca9-9362-7045c6a3afce@github.com>
Message-ID: 

On Fri, 11 Apr 2025 08:51:56 GMT, Aleksey Shipilev  wrote:

>> I think it would be "easier" to shift `@IntrinsicCandidate` to a private `Reference.getImpl/get0` pair of methods, and intrinsify one of those instead. Pretty much like current `clear` and `refersTo` are doing it now. And it would be in line with what Kim is doing in this PR anyway.
>
> On a second thought, I think we should do this shift before this PR, so that it is cleanly backportable. This bug messes with concurrent GC invariants, so it would be nice to fix it in current LTSes.

As far as I can tell, intrinsic selection only applies when the call target is
exactly the intrinsically attributed method. (Possibly after optimizations
that lead to a call to that specific method.) And that's obviously necessary
for correctness of applying intrinsics.

The documentation for `@IntrinsicCandidate` suggests it is "better to make
intrinsics be static methods", but non-static methods are certainly permitted,
and I've found several. In particular, the method in question,
`Reference::get`, has been a virtual intrinsic with at least three
(non-intrinsic) overrides (SoftReference, PhantomReference, and
FinalReference) for a long time.

I did a bit of experimenting, and as far as I can tell, everything works as
expected.  Reference::get is already registered as having
vmIntrinsics::_Reference_get as it's intrinsic_id, and that intrinsic id is
handled by the various code processors, such as being in the dispatch table
that @vnkozlov refreenced.

All of Reference::get, Reference::refersTo, and Reference::clear are subtly
different in the details of how they are implemented and intrinsified, because
there are differences among them.

refersTo is final, but needs different implementations for Reference and
PhantomReference. That distinction is handled via nonpublic virtual
refersToImpl. And those are implemented in terms of separate intrinsified
private native methods because we found that C2 handling of intrinsified
virtual native methods had problems.  If not for that issue, the refersToImpl
methods would be intrinsified virtual native methods.

Reference::clear also needs clearImpl, but for a different reason. There are
places where we want to directly call the implementation of Reference::clear,
ignoring any overrides by derived application classes. That is accomplished by
calling the virtual clearImpl, which has implementations in Reference and
PhantomReference. And the clearImpls are implemented in terms of separate
intrinsified private native methods because of the above mentioned C2 issue.

The native implementations for clear call the same JVM_ReferenceClear helper
function, which uses unknown_referent_no_keepalive to handle the distinction
between weak and phantom strengths.  If we just had the native implementation
we could drop the PhantomReference override.  But this operation also has
intrinsic support, and the intrinsic makes use of the known strength.

Reference::get already has long-standing intrinsic support.  The only thing
being changed here is the ordinary definition of that method.  It needs to
remain virtual, so we don't want to make it directly native, because of the
above mentioned C2 issue.  So we make it call a private native helper
function.  This method is not applicable to either PhantomReference or
FinalReference, as they provide their own implementations, so the native
implementation only needs to support weak strength.

For Reference::get we don't need a separate virtual getImpl.  The reasons for
the xxxImpl methods for refersTo and clear don't apply here.  We could move
the intrinsification from Reference::get to to private native Reference::get0
(without an intervening Impl), to more closely correspond to refersTo and
clear (where the intrinsics are the associated private native methods).  But
that would require renaming the intrinsic id for consistency with the name of
the intrinsified method, and other renamings as well.  I'd considered doing
that initially, but decided that was a bunch of code churn with no benefit.

So in summary, I don't think any changes to this PR are needed based on this
comment thread (at least so far).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2039137923

From mcimadamore at openjdk.org  Fri Apr 11 09:52:35 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 11 Apr 2025 09:52:35 GMT
Subject: RFR: 8353917: jnativescan: Simplify ClassResolver [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 17:07:21 GMT, Jorn Vernee  wrote:

>> `jnativescan` uses the `ClassResolver` class to find both system classes, as well as application classes. In principle, a class resolver supports both iterating over all classes from that particular source, as well as looking up classes by name. However, the `ClassResolver` for system classes doesn't support iterating, and the lookup functionality for `ClassResolvers` from other sources is never used (only iterating).
>> 
>> This patch proposes to split the iterating functionality out of `ClassResolver`. Clients that were using this functionality will switch to using the iteration functionality that is available on `ClassFileSource` directly (whose classes were previously being wrapped in a `ClassResolver`). As a result of this latter change, we can now also let `NativeMethodFinder` operate on individual classes. We just iterate over all the class file sources in `JNativeScanTask`, and feed individual class models to `NativeMethodFinder`. I think this is a good conceptual simplification of `NativeMethodFinder`,
>> 
>> Since `ClassResolver` is now only used for system classes, I've removed it, leaving only its single implementation: `SystemClassResolver`.
>> 
>> Testing: running `langtools_jnativescan` test suite.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Looks good!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24493#pullrequestreview-2759781558

From ihse at openjdk.org  Fri Apr 11 10:21:41 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 11 Apr 2025 10:21:41 GMT
Subject: RFR: 8354320: Changes to jpackage.md cause pandoc warning
In-Reply-To: 
References: 
Message-ID: <_7G9tb5NsJ-VuhfDWQApRphJ3ujRn4VBdBDOuQ2PLI8=.4007e27f-a1db-4b99-af7d-592824baa0c1@github.com>

On Thu, 10 Apr 2025 21:50:10 GMT, Alexey Semenyuk  wrote:

> Escape the dollar sign.

I'm not entirely sure this is a good solution. Yes, it makes pandoc happy and removes the warning, but this is using a pandoc extension and not standard markdown. A standard markdown renderer will show this as the literal `$`, and not just a `$` which is intended.

I will repeat my suggestion to put the special characters inside backticks. Not only will it prevent pandoc from trying to do any expansion, it will also follow a general practice of formatting code where literals the user should type is in monotype. So I think it would kill two birds with one stone.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24585#issuecomment-2796488922

From ihse at openjdk.org  Fri Apr 11 10:25:51 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 11 Apr 2025 10:25:51 GMT
Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables
 available in *.cfg files [v10]
In-Reply-To: 
References: 
 
 
 <48XUp04EgIXYClNpiBYOVe_42cJAljCARwz1-HWUTYA=.7bdd2f12-5487-43fb-be12-c3185749a738@github.com>
 
 
Message-ID: <3giS9Lb1PoXhb2-PezTT3p9tg-RRQIXZT1Ctl2qD8hM=.959412c0-e23a-4fe5-84f8-2fb9a23e8151@github.com>

On Thu, 10 Apr 2025 21:53:39 GMT, Alexey Semenyuk  wrote:

>> I filed https://bugs.openjdk.org/browse/JDK-8354320 to fix the warning
>
> Adding backslash character (``) before the dollar character (`"${"` -> `"${"`) suppressed the warning, and the man page looks as expected.
> 
> PR https://github.com/openjdk/jdk/pull/24585

As I said in that PR, yes, it silences the warning, but it is not standard markdown, and will be rendered incorrectly by a standard markdown renderer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23923#discussion_r2039260553

From jbhateja at openjdk.org  Fri Apr 11 10:25:47 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 11 Apr 2025 10:25:47 GMT
Subject: RFR: 8346230: [perf] scalability issue for the
 specjvm2008::xml.transform workload [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 28 Mar 2025 23:48:34 GMT, Vladimir Ivanov  wrote:

>> The HashMap for caching was deleted. Now it use only ThreadLocal variable without synchronization.
>> According to the specjvm2008::xml.transform workload the performance for low threads counts was not affected and improved for high threads counts. 
>> For the 2 socket server based on Xeon 6780E reported scores are (average for 3 runs):
>> 2x6780E | 1C | 32C | 64C | 96C | 128C | 160C | 192C | 224C | 256C | 288C
>> orig        | 138.9567 | 4127.567 | 8203.907 | 12252.07 | 15496.65 | 16222.91 | 15846.48 | 14758.43 | 14612.34 | 13969.25
>> patched | 139.7067 | 4118.763 | 8352.657 | 12491.14 | 16085.63 | 18101.67 | 21001.52 | 23847.33 | 26481.25 | 28273.93
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8346230: [perf] scalability issue for the specjvm2008::xml.transform workload

src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java line 112:

> 110:         reader = threadHasReader ? rw.reader : null;
> 111:         String factory = System.getProperty(property);
> 112:         if (threadHasReader &&

Please modify the comments to reflect your new behaviour.

src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java line 148:

> 146:         // for this thread, remove it.
> 147:         ReaderWrapper rw = m_readers.get();
> 148:         if (rw != null && rw.reader == reader && reader != null) {

Suggestion:

        if (rw != null && rw.reader == reader) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23185#discussion_r2039236336
PR Review Comment: https://git.openjdk.org/jdk/pull/23185#discussion_r2039246817

From ihse at openjdk.org  Fri Apr 11 10:27:40 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 11 Apr 2025 10:27:40 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 03:35:11 GMT, Sergey Bylokhov  wrote:

>> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
>> 
>> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
>> 
>> Methodology used: 
>> 
>> I have run four different tools for using different heuristics for determining the encoding of a file:
>> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
>> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
>> * enca (targeted towards obscure code pages)
>> * libmagic / `file  --mime-encoding`
>> 
>> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
>> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
>> 
>> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
>> * All files where at least one tool claimed it to be UTF-8
>> * All files where at least one tool claimed it to be *not* UTF-8
>> 
>> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
>> 
>> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure...
>
> src/demo/share/java2d/J2DBench/resources/textdata/arabic.ut8.txt line 11:
> 
>> 9: ???????? ???????????? ?????????????? "??????????????" ???????? ?????????? ?????? ???????? ???? ???????? ???????????? ?????????????????? ???????? ?????? ?????????? ???? ?????? ?????????????? ???? ?????????????? ??????????????????. ?????? ?????? ???????? ???????????? "??????????????" ???????? ???????? ???????? ???????????????? ???????????? ???????????????? ?????? ?????????????? ?????? ?????????? ????.????.????. (IBM)?? ???????? (APPLE)?? ???????????????????? ?????????????? (Hewlett-Packard) ?? ???????????????????? (Microsoft)?? ???????????????? (Oracle) ?? ???? (Sun) ????????????. ?????? ???? ?????????????????? ?????????????????? ?????????????? (?????? ?????? ?????????????? "????????" "JAVA" ???????? "?????? ???? ????" "XML" ???????? ???????????? ???????????? ??????????????????) ?????????? ?????????????? "??????????????". ?????????? ?????? ?????? ?? ?????? "??????????????" ???? ???????????????????? ???????????????? ???????????? ???????????????? ???????????????????? ???????? ?????
 ?????  (ISO 10646) .
>> 10: 
>> 11: ???? ???????? ???????????? "??????????????" ?????????????? ?????????????? ???????? ?????????????? ?????????????? ?????????? ???? ?????? ???????????????????? ?????????????? ???? ?????????? ?????????????????? ?????????? ???????????? ???? ????????????. ?????? ?????????????? "??????????????" ???? ???????? ?????????????????? ?????????? ?????? ?????????? ???????? ???????????? ???? ?????????????? ?????????????????? ?????????????????? ?????????????? ??????????????. ?????? ???? ?????????????? "??????????????" ???????????????? ?????????????? ???? ?????????? ???????????????? ?????? ???????????? ?????????????????? ?????? ???? ?????? ???? ?????????????? ???? ???????????????? ???????? ?????? ???? ???????? ???? ???????????? ?????????? ?????????? ?????? ???????????? ???????????? ?????????????? ???? ?????????? ???? ??????????. ?????????????? ?????? ?????????????? "??????????????" ?????????? ???????????????? ???? ???????????????? ?????? ?????????????? ???????????????? ???????????????? ?????? ??
 ?? ?????????? ?????????????????? ???????? ?????????? ?????????????? ?????????????? ?????????????? ???????????????? ???????????? ???????? ?????? ???? ???????????? ?????? ????????????????.
> 
> Looks like most of the changes in java2d/* are related to spaces at the end of the line?

No, that are just incidental changes (see https://github.com/openjdk/jdk/pull/24566#issuecomment-2795201480). The actual change for the java2d files is the removal of the initial UTF-8 BOM. Github has a hard time showing this though, since the BOM is not visible.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2039258980

From eirbjo at openjdk.org  Fri Apr 11 10:27:40 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 11 Apr 2025 10:27:40 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 11 Apr 2025 10:21:32 GMT, Magnus Ihse Bursie  wrote:

>> src/demo/share/java2d/J2DBench/resources/textdata/arabic.ut8.txt line 11:
>> 
>>> 9: ???????? ???????????? ?????????????? "??????????????" ???????? ?????????? ?????? ???????? ???? ???????? ???????????? ?????????????????? ???????? ?????? ?????????? ???? ?????? ?????????????? ???? ?????????????? ??????????????????. ?????? ?????? ???????? ???????????? "??????????????" ???????? ???????? ???????? ???????????????? ???????????? ???????????????? ?????? ?????????????? ?????? ?????????? ????.????.????. (IBM)?? ???????? (APPLE)?? ???????????????????? ?????????????? (Hewlett-Packard) ?? ???????????????????? (Microsoft)?? ???????????????? (Oracle) ?? ???? (Sun) ????????????. ?????? ???? ?????????????????? ?????????????????? ?????????????? (?????? ?????? ?????????????? "????????" "JAVA" ???????? "?????? ???? ????" "XML" ???????? ???????????? ???????????? ??????????????????) ?????????? ?????????????? "??????????????". ?????????? ?????? ?????? ?? ?????? "??????????????" ???? ???????????????????? ???????????????? ???????????? ???????????????? ???????????????????? ???????? ????
 ??????  (ISO 10646) .
>>> 10: 
>>> 11: ???? ???????? ???????????? "??????????????" ?????????????? ?????????????? ???????? ?????????????? ?????????????? ?????????? ???? ?????? ???????????????????? ?????????????? ???? ?????????? ?????????????????? ?????????? ???????????? ???? ????????????. ?????? ?????????????? "??????????????" ???? ???????? ?????????????????? ?????????? ?????? ?????????? ???????? ???????????? ???? ?????????????? ?????????????????? ?????????????????? ?????????????? ??????????????. ?????? ???? ?????????????? "??????????????" ???????????????? ?????????????? ???? ?????????? ???????????????? ?????? ???????????? ?????????????????? ?????? ???? ?????? ???? ?????????????? ???? ???????????????? ???????? ?????? ???? ???????? ???? ???????????? ?????????? ?????????? ?????? ???????????? ???????????? ?????????????? ???? ?????????? ???? ??????????. ?????????????? ?????? ?????????????? "??????????????" ?????????? ???????????????? ???? ???????????????? ?????? ?????????????? ???????????????? ???????????????? ?????? ?
 ??? ?????????? ?????????????????? ???????? ?????????? ?????????????? ?????????????? ?????????????? ???????????????? ???????????? ???????? ?????? ???? ???????????? ?????? ????????????????.
>> 
>> Looks like most of the changes in java2d/* are related to spaces at the end of the line?
>
> No, that are just incidental changes (see https://github.com/openjdk/jdk/pull/24566#issuecomment-2795201480). The actual change for the java2d files is the removal of the initial UTF-8 BOM. Github has a hard time showing this though, since the BOM is not visible.

I found the side-by-side diff in IntelliJ useful here, as it said "UTF-8 BOM" vs. "UTF-8".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2039263227

From ihse at openjdk.org  Fri Apr 11 10:27:40 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 11 Apr 2025 10:27:40 GMT
Subject: Integrated: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie  wrote:

> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
> 
> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
> 
> Methodology used: 
> 
> I have run four different tools for using different heuristics for determining the encoding of a file:
> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
> * enca (targeted towards obscure code pages)
> * libmagic / `file  --mime-encoding`
> 
> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
> 
> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
> * All files where at least one tool claimed it to be UTF-8
> * All files where at least one tool claimed it to be *not* UTF-8
> 
> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
> 
> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure binary files, but without any telling exten...

This pull request has now been integrated.

Changeset: d4e194bc
Author:    Magnus Ihse Bursie 
URL:       https://git.openjdk.org/jdk/commit/d4e194bc463ff3ad09e55cbb96bea00283679ce6
Stats:     32 lines in 13 files changed: 0 ins; 2 del; 30 mod

8354266: Fix non-UTF-8 text encoding

Reviewed-by: rgiulietti, erikj, naoto, eirbjo

-------------

PR: https://git.openjdk.org/jdk/pull/24566

From mli at openjdk.org  Fri Apr 11 10:48:35 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 11 Apr 2025 10:48:35 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L [v7]
In-Reply-To: <4cfNjUGKQ4o4DrUBM_-JqcAiRlXp06y-NuipEo9cjTU=.65bdc5e4-4d5c-44ae-9eff-279b58a4b336@github.com>
References: 
 <317DYBGa3NAUfowhgTFeq8Crezuz-mV9io6nW1IXccc=.d37f6b47-ac06-4234-9162-8aca891630d7@github.com>
 <4cfNjUGKQ4o4DrUBM_-JqcAiRlXp06y-NuipEo9cjTU=.65bdc5e4-4d5c-44ae-9eff-279b58a4b336@github.com>
Message-ID: 

On Fri, 11 Apr 2025 04:07:45 GMT, Fei Yang  wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   enable more test
>
> src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 2173:
> 
>> 2171:       break;
>> 2172:     case BoolTest::ge:
>> 2173:       cmov_cmp_fp_ge(op1, op2, dst, src, is_single);
> 
> This calls `cmov_cmp_fp_ge` and `cmov_cmp_fp_gt` assembler routines for `BoolTest::ge` and `BoolTest::gt` respectively, but these two assembler routines are NOT implemented in file macroAssembler_riscv.cpp. That seems a bit confusing to me. How about making these two cases unreachable in this function? Or simply implement these two assembler routines?

Make sense, I'll remove the unimplemented code and mvoe the check to `enc_cmove_cmp_fp`. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24490#discussion_r2039291255

From mli at openjdk.org  Fri Apr 11 10:48:34 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 11 Apr 2025 10:48:34 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L [v8]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> Can you help to review this patch?
> On riscv, CMoveI/L already were implemented, but there are some gap:
> 1. CMoveI/L does not support comparison with float/double, corresponding tests are not turn on either.
> 2. Some optimization of C2 is not turned on, e.g. `Phi -> CMove -> min_max`.
> 3. lack of some corresponding performance tests.
> 
> Also there are some issue with current Zicond:
> 1. UseZicond is turned on automatically by hwprobe, but jmh tests show that it's not always bring benefit, in some situation it even brings regression, the reason is the generated code by Zicond is much larger than branch version, in particular when it's in a loop and unrolled.
> 
> This patch on riscv is to:
> 1. add CMoveI/L comparing float/double, and corresponding tests,
> 2. enable more C2 optimization,
> 3. add more benchmark tests,
> 4. turn off UseZicond by default.
> 
> Thanks!
> 
> ## Performance
> 
> ### MinMax
> test data
> 
> Benchmark | Mode | Cnt | Score - master | Score - master+UseZbb | Score - -master+UseZicond | Score - master+UseZicond+UseZbb | Score - cmovei | Score - cmovei+UseZbb | Score - cmovei+UseZicond | Score - cmovei+UseZicond+UseZbb | Error | Units | Opt (master/cmovei)
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> o.o.b.vm.compiler.IfMinMax.testReductionInt | avgt | 40 | 17152.075 | 17216.592 | 17272.493 | 17296.89 | 17127.844 | 17036.605 | 17299.333 | 17250.566 | 73.179 | ns/op | 1.001
> o.o.b.vm.compiler.IfMinMax.testReductionLong | avgt | 40 | 19770.828 | 19967.578 | 20268.905 | 20166.165 | 20065.552 | 20059.095 | 20161.914 | 20151.295 | 131.428 | ns/op | 0.985
> o.o.b.vm.compiler.IfMinMax.testSingleInt | avgt | 40 | 114.734 | 114.402 | 114.887 | 114.384 | 114.4 | 110.631 | 112.162 | 110.915 | 0.333 | ns/op | 1.003
> o.o.b.vm.compiler.IfMinMax.testSingleLong | avgt | 40 | 121.53 | 121.711 | 120.91 | 121.665 | 121.309 | 120.57 | 118.639 | 119.373 | 0.451 | ns/op | 1.002
> o.o.b.vm.compiler.IfMinMax.testVectorInt | avgt | 40 | 60130.165 | 60062.303 | 61839.776 | 61895.194 | 15887.398 | 15924.502 | 15874.835 | 15667.936 | 101.94 | ns/op | 3.785
> o.o.b.vm.compiler.IfMinMax.testVectorLong | avgt | 40 | 63855.379 | 6309...

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  minors

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24490/files
  - new: https://git.openjdk.org/jdk/pull/24490/files/7860aba1..67fd2681

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24490&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24490&range=06-07

  Stats: 36 lines in 4 files changed: 11 ins; 17 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/24490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24490/head:pull/24490

PR: https://git.openjdk.org/jdk/pull/24490

From shade at openjdk.org  Fri Apr 11 10:54:35 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Apr 2025 10:54:35 GMT
Subject: RFR: 8352565: Add native method implementation of Reference.get()
 [v4]
In-Reply-To: 
References: 
 
 
 
 
 <-oOK2Dh2vnn9Qc5MBRiKoeauVFVPPV_9fKMqAQwjFfY=.b20b09d9-a268-4ca9-9362-7045c6a3afce@github.com>
 
Message-ID: 

On Fri, 11 Apr 2025 09:09:05 GMT, Kim Barrett  wrote:

>> On a second thought, I think we should do this shift before this PR, so that it is cleanly backportable. This bug messes with concurrent GC invariants, so it would be nice to fix it in current LTSes.
>
> As far as I can tell, intrinsic selection only applies when the call target is
> exactly the intrinsically attributed method. (Possibly after optimizations
> that lead to a call to that specific method.) And that's obviously necessary
> for correctness of applying intrinsics.
> 
> The documentation for `@IntrinsicCandidate` suggests it is "better to make
> intrinsics be static methods", but non-static methods are certainly permitted,
> and I've found several. In particular, the method in question,
> `Reference::get`, has been a virtual intrinsic with at least three
> (non-intrinsic) overrides (SoftReference, PhantomReference, and
> FinalReference) for a long time.
> 
> I did a bit of experimenting, and as far as I can tell, everything works as
> expected.  Reference::get is already registered as having
> vmIntrinsics::_Reference_get as it's intrinsic_id, and that intrinsic id is
> handled by the various code processors, such as being in the dispatch table
> that @vnkozlov refreenced.
> 
> All of Reference::get, Reference::refersTo, and Reference::clear are subtly
> different in the details of how they are implemented and intrinsified, because
> there are differences among them.
> 
> refersTo is final, but needs different implementations for Reference and
> PhantomReference. That distinction is handled via nonpublic virtual
> refersToImpl. And those are implemented in terms of separate intrinsified
> private native methods because we found that C2 handling of intrinsified
> virtual native methods had problems.  If not for that issue, the refersToImpl
> methods would be intrinsified virtual native methods.
> 
> Reference::clear also needs clearImpl, but for a different reason. There are
> places where we want to directly call the implementation of Reference::clear,
> ignoring any overrides by derived application classes. That is accomplished by
> calling the virtual clearImpl, which has implementations in Reference and
> PhantomReference. And the clearImpls are implemented in terms of separate
> intrinsified private native methods because of the above mentioned C2 issue.
> 
> The native implementations for clear call the same JVM_ReferenceClear helper
> function, which uses unknown_referent_no_keepalive to handle the distinction
> between weak and phantom strengths.  If we just had the native implementation
> we could drop the PhantomReference override.  But this operation also has
> intrinsic support, and the intrinsic makes use of the known strength.
> 
> Reference::get already has long-standing intrinsic support.  The only thing
> being ch...

I think I understand the intrinsic matchers machinery better now: it indeed binds intrinsics to concrete methods. So virtual overrides are supposed to have no difference. Also, I tried a few examples where I thought it should fail, and it does not. I added some diagnostic checks around interpreter, and they do not fail:


diff --git a/src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp b/src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
index bdc2ca908bd..255fa6443af 100644
--- a/src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
+++ b/src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
@@ -652,6 +652,21 @@ address TemplateInterpreterGenerator::generate_Reference_get_entry(void) {
   // rdx: scratch
   // rdi: scratch
 
+  if (UseNewCode) {
+    Label L_good;
+    __ push(rscratch1);
+    __ push(rscratch2);
+
+    __ load_klass(rscratch1, rax, rscratch2);
+    __ cmpb(Address(rscratch1, in_bytes(InstanceKlass::reference_type_offset())), REF_PHANTOM);
+    __ jccb(Assembler::notEqual, L_good);
+    __ stop("PHANTOM REFERENCE CALLED WITH INTERPRETER REFERENCE.GET INTRINSIC");
+    __ bind(L_good);
+
+    __ pop(rscratch2);
+    __ pop(rscratch1);
+  }
+
   // Load the value of the referent field.
   const Address field_address(rax, referent_offset);
   __ load_heap_oop(rax, field_address, /*tmp1*/ rbx, ON_WEAK_OOP_REF);


I tried C2 IR test, and it works fine: we return constant `0` for `PhantomReferences`, like we would expect. I am going to RFR that test separately.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2039300718

From mdoerr at openjdk.org  Fri Apr 11 11:08:30 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 11 Apr 2025 11:08:30 GMT
Subject: RFR: 8354189: Remove JLI_ReportErrorMessageSys on Windows [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 07:11:19 GMT, Matthias Baesken  wrote:

>> JLI_ReportErrorMessageSys is not used any more on Windows, so we can remove it and make it UNIX-only (there a still a few remaining usages).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust COPYRIGHT years

LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24563#pullrequestreview-2759974114

From jvernee at openjdk.org  Fri Apr 11 11:18:44 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 11 Apr 2025 11:18:44 GMT
Subject: RFR: 8353917: jnativescan: Simplify ClassResolver [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 17:07:21 GMT, Jorn Vernee  wrote:

>> `jnativescan` uses the `ClassResolver` class to find both system classes, as well as application classes. In principle, a class resolver supports both iterating over all classes from that particular source, as well as looking up classes by name. However, the `ClassResolver` for system classes doesn't support iterating, and the lookup functionality for `ClassResolvers` from other sources is never used (only iterating).
>> 
>> This patch proposes to split the iterating functionality out of `ClassResolver`. Clients that were using this functionality will switch to using the iteration functionality that is available on `ClassFileSource` directly (whose classes were previously being wrapped in a `ClassResolver`). As a result of this latter change, we can now also let `NativeMethodFinder` operate on individual classes. We just iterate over all the class file sources in `JNativeScanTask`, and feed individual class models to `NativeMethodFinder`. I think this is a good conceptual simplification of `NativeMethodFinder`,
>> 
>> Since `ClassResolver` is now only used for system classes, I've removed it, leaving only its single implementation: `SystemClassResolver`.
>> 
>> Testing: running `langtools_jnativescan` test suite.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24493#issuecomment-2796606870

From jvernee at openjdk.org  Fri Apr 11 11:18:45 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 11 Apr 2025 11:18:45 GMT
Subject: Integrated: 8353917: jnativescan: Simplify ClassResolver
In-Reply-To: 
References: 
Message-ID: 

On Mon, 7 Apr 2025 16:36:07 GMT, Jorn Vernee  wrote:

> `jnativescan` uses the `ClassResolver` class to find both system classes, as well as application classes. In principle, a class resolver supports both iterating over all classes from that particular source, as well as looking up classes by name. However, the `ClassResolver` for system classes doesn't support iterating, and the lookup functionality for `ClassResolvers` from other sources is never used (only iterating).
> 
> This patch proposes to split the iterating functionality out of `ClassResolver`. Clients that were using this functionality will switch to using the iteration functionality that is available on `ClassFileSource` directly (whose classes were previously being wrapped in a `ClassResolver`). As a result of this latter change, we can now also let `NativeMethodFinder` operate on individual classes. We just iterate over all the class file sources in `JNativeScanTask`, and feed individual class models to `NativeMethodFinder`. I think this is a good conceptual simplification of `NativeMethodFinder`,
> 
> Since `ClassResolver` is now only used for system classes, I've removed it, leaving only its single implementation: `SystemClassResolver`.
> 
> Testing: running `langtools_jnativescan` test suite.

This pull request has now been integrated.

Changeset: 8bb0ca49
Author:    Jorn Vernee 
URL:       https://git.openjdk.org/jdk/commit/8bb0ca49715d8c713d6319b00a7684564ba57a9b
Stats:     374 lines in 5 files changed: 150 ins; 191 del; 33 mod

8353917: jnativescan: Simplify ClassResolver

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/24493

From jlahoda at openjdk.org  Fri Apr 11 11:20:30 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 11 Apr 2025 11:20:30 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v6]
In-Reply-To: 
References: 
Message-ID: 

> This is a patch to finalize the module imports feature. Please see:
> https://bugs.openjdk.org/browse/JDK-8344700

Jan Lahoda 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:

 - Adjusting ToolProviderTest to the updated persistence handling.
 - Merge branch 'master' into JDK-8344708
 - Reflecting review feedback: cleanup formatting in ModuleInfo.
 - Reflecting review feedback - avoiding hardcoded constants.
 - Fixing test.
 - Cleanup, fixing tests.
 - Adjusting JShell defaults.
 - Fixing tests.
 - Cleanup - updated specification will permit requires transitive java.base; for all classfile versions; java.se no longer participates in preview.
 - Cleanup.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/124c1cf4...4c14c3b0

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23801/files
  - new: https://git.openjdk.org/jdk/pull/23801/files/029e0dd5..4c14c3b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23801&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23801&range=04-05

  Stats: 213792 lines in 4489 files changed: 97109 ins; 91547 del; 25136 mod
  Patch: https://git.openjdk.org/jdk/pull/23801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23801/head:pull/23801

PR: https://git.openjdk.org/jdk/pull/23801

From mbaesken at openjdk.org  Fri Apr 11 11:35:39 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 11 Apr 2025 11:35:39 GMT
Subject: Integrated: 8354189: Remove JLI_ReportErrorMessageSys on Windows
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Apr 2025 08:03:58 GMT, Matthias Baesken  wrote:

> JLI_ReportErrorMessageSys is not used any more on Windows, so we can remove it and make it UNIX-only (there are still a few remaining usages).

This pull request has now been integrated.

Changeset: b5d2e254
Author:    Matthias Baesken 
URL:       https://git.openjdk.org/jdk/commit/b5d2e25478c6a8b6f3d8aae71f8a6745a11b1c9e
Stats:     80 lines in 3 files changed: 4 ins; 73 del; 3 mod

8354189: Remove JLI_ReportErrorMessageSys on Windows

Reviewed-by: alanb, mdoerr

-------------

PR: https://git.openjdk.org/jdk/pull/24563

From mbaesken at openjdk.org  Fri Apr 11 11:35:38 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 11 Apr 2025 11:35:38 GMT
Subject: RFR: 8354189: Remove JLI_ReportErrorMessageSys on Windows [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 07:11:19 GMT, Matthias Baesken  wrote:

>> JLI_ReportErrorMessageSys is not used any more on Windows, so we can remove it and make it UNIX-only (there are still a few remaining usages).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust COPYRIGHT years

Hi Alan and Martin, thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24563#issuecomment-2796648129

From asemenyuk at openjdk.org  Fri Apr 11 12:55:26 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 11 Apr 2025 12:55:26 GMT
Subject: RFR: 8354320: Changes to jpackage.md cause pandoc warning
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Apr 2025 21:50:10 GMT, Alexey Semenyuk  wrote:

> Escape the dollar sign.

"`${`"

emits a slightly different warning:

[WARNING] Could not convert TeX math ) and the first following non-alphanumeric character. Alternatively, it can be enclosed between "`, rendering as TeX:
  e enclosed between "`
                     ^
  unexpected '"' 


Similar with

`${`

the warning is:

[WARNING] Could not convert TeX math ) and the first following non-alphanumeric character. Alternatively, it can be enclosed between "`, rendering as TeX:
  e enclosed between "`
                     ^
  unexpected '"' 


It seems like it can't handle the dollar character unless it is escaped with the backslash.

Even though raw jpackage.md renders the backslash, man and HTML outputs look correct.

I'm not an expert in pandoc or markdown. If you have any other ideas about how to fix it, I'll be happy to try them out.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24585#issuecomment-2796836264

From rcastanedalo at openjdk.org  Fri Apr 11 13:01:49 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 11 Apr 2025 13:01:49 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v33]
In-Reply-To: <5FzYDFpFOksmAGM5RV0gGk2eDAdinlDCGo8_37eUeEA=.5f96c37e-7b10-41b4-a607-fc7a665abd67@github.com>
References: 
 <5FzYDFpFOksmAGM5RV0gGk2eDAdinlDCGo8_37eUeEA=.5f96c37e-7b10-41b4-a607-fc7a665abd67@github.com>
Message-ID: 

On Thu, 10 Apr 2025 10:02:40 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 two additional commits since the last revision:
> 
>  - * indentation fix
>  - * remove support for 32 bit x86 in the barrier generation code, following latest changes from @shade

Thank you for addressing my comments, Thomas!
The new x64 version of `G1BarrierSetAssembler::gen_write_ref_array_post_barrier` looks correct, but I think it could be significantly simplified, here is my suggestion which is more similar to the aarch64 version: https://github.com/robcasloz/jdk/commit/fbedc0ae1ec5fcfa95b00ad354986885c7a56ce0 (note: did not test it thoroughly).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2796850628

From jengebr at amazon.com  Fri Apr 11 13:10:27 2025
From: jengebr at amazon.com (Engebretson, John)
Date: Fri, 11 Apr 2025 13:10:27 +0000
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: 
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 
 <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 
 
 <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
 
 <3f1c69a7ac5946809d2af850d7d59db9@amazon.com>
 
 
 
Message-ID: <4741eceb3beb40c2bc82613c67836d66@amazon.com>

I?m prototyping the generic allocator you describe and it?s extremely effective for Objects ? but I?m hamstrung by trying to use generics on primitive byte.  I?m not aware of a way to work around that, and changing the array from byte[] to Byte[] would be a terrible idea, so I think we?re looking at two different allocators.  The template suggested by Archie may help implement that, but ultimately it?ll be multiple classes.


My updated PR still pending (I want to do some cleanup) but I got some interesting results:

Replacing MOS with VariableLengthByteArray.asByteArrayOutputStream(): works great, perf is excellent.  A comment  on the PR suggested additional views such as InputStream and Channel, they will certainly work but will take a little time to implement.  I really like how much capability this brings.

The Object variant ?VariableLengthObjectArray? came together very easily, however the performance characteristics of my first view (List) gave me a few surprises.  Here?s the evaluation:

  1.  This grows more efficiently than either ArrayList or LinkedList.  Some variation across sizes.
  2.  This has higher capacity than ArrayList (no 2GB cap) or LinkedList (this is denser in heap)
  3.  This achieves log(n) on random inserts/removes, since it only modifies one segment.  That beats ArrayList (linear) or LinkedList (linear).
  4.  Random accesses such as get(5) are log(n), which is between ArrayList (constant) and LinkedList (linear).
  5.  Iterating is just a little slower than ArrayList thanks to overhead, but substantially faster than LinkedList
  6.  Head modifications such as LinkedList/Queue is log(n), which is better than ArrayList (linear) but worse than LinkedList (constant).

It seems like a good general-purpose list but I wouldn?t recommend it as a direct replacement for either ArrayList or LinkedList; in the former case the risk is slower random accesses, and in the latter the risk is to head modifications.

I can test new permutations of this fairly quickly, suggestions are welcome.

   John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcastanedalo at openjdk.org  Fri Apr 11 13:10:33 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 11 Apr 2025 13:10:33 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v33]
In-Reply-To: <5FzYDFpFOksmAGM5RV0gGk2eDAdinlDCGo8_37eUeEA=.5f96c37e-7b10-41b4-a607-fc7a665abd67@github.com>
References: 
 <5FzYDFpFOksmAGM5RV0gGk2eDAdinlDCGo8_37eUeEA=.5f96c37e-7b10-41b4-a607-fc7a665abd67@github.com>
Message-ID: 

On Thu, 10 Apr 2025 10:02:40 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 two additional commits since the last revision:
> 
>  - * indentation fix
>  - * remove support for 32 bit x86 in the barrier generation code, following latest changes from @shade

> G1 sets UseCondCardMark to true by default. The conditional card mark corresponds to the third filter in the write barrier now, and since I decided to keep all filters for this change, it makes sense to directly use this mechanism.

Do you have performance results for `-UseCondCardMark` vs. `+UseCondCardMark`? The benefit of `+UseCondCardMark` is not obvious from looking at the generated barrier code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2796872496

From ihse at openjdk.org  Fri Apr 11 13:21:25 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 11 Apr 2025 13:21:25 GMT
Subject: RFR: 8354320: Changes to jpackage.md cause pandoc warning
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Apr 2025 21:50:10 GMT, Alexey Semenyuk  wrote:

> Escape the dollar sign.

Oh, that's too bad. :( Weird that pandoc tries to modify stuff inside ``. I think the better solution then is to pass `-tex_math_dollars` to pandoc to stop it from trying to parse the dollar sign. We should not be using the TeX math extension anyway. I'll whip up a build patch, one sec...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24585#issuecomment-2796899816

From asemenyuk at openjdk.org  Fri Apr 11 13:33:10 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 11 Apr 2025 13:33:10 GMT
Subject: RFR: 8354320: Changes to jpackage.md cause pandoc warning
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Apr 2025 21:50:10 GMT, Alexey Semenyuk  wrote:

> Escape the dollar sign.

Meanwhile, I fixed a case of missing escape backslash in the following paragraph. I verified that it is rendered properly in raw markdown and in pandoc output.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24585#issuecomment-2796924054

From asemenyuk at openjdk.org  Fri Apr 11 13:33:09 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 11 Apr 2025 13:33:09 GMT
Subject: RFR: 8354320: Changes to jpackage.md cause pandoc warning [v2]
In-Reply-To: 
References: 
Message-ID: 

> Escape the dollar sign.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Add missing backslash character

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24585/files
  - new: https://git.openjdk.org/jdk/pull/24585/files/6709a723..33364c72

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24585&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24585&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24585.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24585/head:pull/24585

PR: https://git.openjdk.org/jdk/pull/24585

From ihse at openjdk.org  Fri Apr 11 13:44:25 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 11 Apr 2025 13:44:25 GMT
Subject: RFR: 8354320: Changes to jpackage.md cause pandoc warning [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 13:33:09 GMT, Alexey Semenyuk  wrote:

>> Escape the dollar sign.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing backslash character

Try this patch:

diff --git a/make/autoconf/basic_tools.m4 b/make/autoconf/basic_tools.m4
index eac14207b1d..516529116c3 100644
--- a/make/autoconf/basic_tools.m4
+++ b/make/autoconf/basic_tools.m4
@@ -468,7 +468,14 @@ AC_DEFUN_ONCE([BASIC_SETUP_PANDOC],
     AC_MSG_CHECKING([if the pandoc smart extension needs to be disabled for markdown])
     if $PANDOC --list-extensions | $GREP -q '+smart'; then
       AC_MSG_RESULT([yes])
-      PANDOC_MARKDOWN_FLAG="markdown-smart"
+      PANDOC_MARKDOWN_FLAG="$PANDOC_MARKDOWN_FLAG-smart"
+    else
+      AC_MSG_RESULT([no])
+    fi
+    AC_MSG_CHECKING([if the pandoc tex_math_dollars extension needs to be disabled for markdown])
+    if $PANDOC --list-extensions | $GREP -q '+tex_math_dollars'; then
+      AC_MSG_RESULT([yes])
+      PANDOC_MARKDOWN_FLAG="$PANDOC_MARKDOWN_FLAG-tex_math_dollars"
     else
       AC_MSG_RESULT([no])
     fi


(and remove the \ in front of $).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24585#issuecomment-2796953675

From asemenyuk at openjdk.org  Fri Apr 11 13:50:04 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 11 Apr 2025 13:50:04 GMT
Subject: RFR: 8354320: Changes to jpackage.md cause pandoc warning [v3]
In-Reply-To: 
References: 
Message-ID: 

> Escape the dollar sign.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Disable tex_math_dollars extension

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24585/files
  - new: https://git.openjdk.org/jdk/pull/24585/files/33364c72..c9d11ffa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24585&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24585&range=01-02

  Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24585.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24585/head:pull/24585

PR: https://git.openjdk.org/jdk/pull/24585

From asemenyuk at openjdk.org  Fri Apr 11 13:50:04 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 11 Apr 2025 13:50:04 GMT
Subject: RFR: 8354320: Changes to jpackage.md cause pandoc warning [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 13:33:09 GMT, Alexey Semenyuk  wrote:

>> Escape the dollar sign.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing backslash character

Ironically, I came up with the same patch a few minutes ago. Even the change to `PANDOC_MARKDOWN_FLAG="$PANDOC_MARKDOWN_FLAG-smart"` is the same.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24585#issuecomment-2796964704

From asemenyuk at openjdk.org  Fri Apr 11 14:24:31 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 11 Apr 2025 14:24:31 GMT
Subject: RFR: 8354320: Changes to jpackage.md cause pandoc warning [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 13:50:04 GMT, Alexey Semenyuk  wrote:

>> Escape the dollar sign.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable tex_math_dollars extension

With the latest fix, the warning is gone, the raw markdown looks as expected when viewed online, and the man output looks correct.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24585#issuecomment-2797061234

From viktor.klang at oracle.com  Fri Apr 11 14:26:50 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Fri, 11 Apr 2025 14:26:50 +0000
Subject: java.lang.String hashCode and @Stable ?
In-Reply-To: <920421036.220248445.1744362266698.JavaMail.zimbra@univ-eiffel.fr>
References: <500256835.218906672.1744276709174.JavaMail.zimbra@univ-eiffel.fr>
 
 <920421036.220248445.1744362266698.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: 

Another option is to make the internal stored hash a long and then the first part can be used to track whether it has been computed and then just cast the long to an int to retrieve the value. If it has been computed, one bit is flipped in the upper 32 bits. Then a read is just a single long read + int cast, and a write is just the computed hashCode plus an OR.

The main downside of course is that it adds 3 bytes to each string (of course alignment and padding etc might change that overhead).


@Stable private long hash; // Default to 0

public int hashCode() {
    long h = hash;
    if ((h & ~(1L << 32)) == 0) // if calculated bit is not set, the calculate
        hash = h = (1L << 32) | (isLatin1()
            ? StringLatin1.hashCode(value)
            : StringUTF16.hashCode(value));
    return (int)h;
}


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev  on behalf of forax at univ-mlv.fr 
Sent: Friday, 11 April 2025 11:04
To: Chen Liang 
Cc: core-libs-dev 
Subject: Re: java.lang.String hashCode and @Stable ?



________________________________
From: "Chen Liang" 
To: "Remi Forax" , "core-libs-dev" 
Sent: Thursday, April 10, 2025 8:16:39 PM
Subject: Re: java.lang.String hashCode and @Stable ?
Hi Remi,
I think this is probably due to these fields being added too early - the stable on string byte array is also added lately.

That said, I don't think adding stable on both fields completely resolves the constant folding issues around string hash code. The current code can only constant fold non-zero hash; a zero hash is folded to a read to hash field, which cannot fold further because it's a read of the default value from a stable field.
A solution may be to change hashIsZero to a byte field indicating 3 states - hash unset (0), hash computed to field, hash computed and is zero. This allows the zero hash to constant fold as well at the cost of non-constant hash access performance, as now there are two reads.

yes,
and obviously, it has to be done without introducing a perf regression if the String is not constant folded.

I think it would be nice to try that as a follow-up of JDK-8354300.


Also this reminds me of https://bugs.openjdk.org/browse/JDK-8332249 - maybe Method::hashCode was hot because the string hash code could not fold.

Usually in framework like Spring, Method are cached either by the framework or by java.lang.Class own cache so the Method itself is rarely a constant.


Regards, Chen

regards,
R?mi

________________________________
From: core-libs-dev  on behalf of Remi Forax 
Sent: Thursday, April 10, 2025 4:18 AM
To: core-libs-dev 
Subject: java.lang.String hashCode and @Stable ?

Question,
why String.hash and String.hashIsZero are not declared @Stable ?

regards,
R?mi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcastanedalo at openjdk.org  Fri Apr 11 14:30:32 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 11 Apr 2025 14:30:32 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v33]
In-Reply-To: <5FzYDFpFOksmAGM5RV0gGk2eDAdinlDCGo8_37eUeEA=.5f96c37e-7b10-41b4-a607-fc7a665abd67@github.com>
References: 
 <5FzYDFpFOksmAGM5RV0gGk2eDAdinlDCGo8_37eUeEA=.5f96c37e-7b10-41b4-a607-fc7a665abd67@github.com>
Message-ID: 

On Thu, 10 Apr 2025 10:02:40 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 two additional commits since the last revision:
> 
>  - * indentation fix
>  - * remove support for 32 bit x86 in the barrier generation code, following latest changes from @shade

The compiler-related parts of this change (including x64 and aarch64 changes) look good! These are the files I reviewed:
- `src/hotspot/share/gc/g1/g1BarrierSet*`
- `src/hotspot/share/gc/g1/{c1,c2}`
- `src/hotspot/cpu/{x86,aarch64}`
- `test/hotspot/jtreg/compiler`
- `test/hotspot/jtreg/testlibrary_tests`

-------------

Marked as reviewed by rcastanedalo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-2760546283

From archie.cobbs at gmail.com  Fri Apr 11 15:15:27 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 11 Apr 2025 10:15:27 -0500
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: <4741eceb3beb40c2bc82613c67836d66@amazon.com>
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 
 <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 
 
 <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
 
 <3f1c69a7ac5946809d2af850d7d59db9@amazon.com>
 
 
 
 <4741eceb3beb40c2bc82613c67836d66@amazon.com>
Message-ID: 

On Fri, Apr 11, 2025 at 8:11?AM Engebretson, John 
wrote:

> It seems like a good general-purpose list but I wouldn?t recommend it as a
> direct replacement for either ArrayList or LinkedList; in the former case
> the risk is slower random accesses, and in the latter the risk is to head
> modifications.
>

Interesting results. However I don't think comparing this to both ArrayList
and LinkedList is really fair. Developers choose an implementation based on
how they know they are going to use it: If they are just adding stuff, they
choose ArrayList. If they know they need to insert/remove in the middle,
they choose LinkedList. If they need to add/remove from both ends, they
choose ArrayDeque. Etc.

So the optimal design changes depending on which "flavor" of list usage the
developer is implying when they choose some implementation class.

E.g., if you wanted to target the "ArrayList flavor', then you'd use fixed
size, power-of-two segments. Then get() remains constant time, and insert
and remove remain as painfully slow as ever, but the common "list builder"
usage pattern of "append, append, append, ..., use read-only thereafter"
gets a lot faster.

OTOH variable-sized chunks makes lots of sense for the "LinkedList" flavor.
In fact you could have a LinkedList that just uses an
ArrayList> internally :)

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vromero at openjdk.org  Fri Apr 11 15:19:31 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 11 Apr 2025 15:19:31 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 11:20:30 GMT, Jan Lahoda  wrote:

>> This is a patch to finalize the module imports feature. Please see:
>> https://bugs.openjdk.org/browse/JDK-8344700
>
> Jan Lahoda 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:
> 
>  - Adjusting ToolProviderTest to the updated persistence handling.
>  - Merge branch 'master' into JDK-8344708
>  - Reflecting review feedback: cleanup formatting in ModuleInfo.
>  - Reflecting review feedback - avoiding hardcoded constants.
>  - Fixing test.
>  - Cleanup, fixing tests.
>  - Adjusting JShell defaults.
>  - Fixing tests.
>  - Cleanup - updated specification will permit requires transitive java.base; for all classfile versions; java.se no longer participates in preview.
>  - Cleanup.
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/950110ae...4c14c3b0

lg

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23801#pullrequestreview-2760679225

From archie.cobbs at gmail.com  Fri Apr 11 15:41:40 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 11 Apr 2025 10:41:40 -0500
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: 
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 
 <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 
 
 <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
 
 <3f1c69a7ac5946809d2af850d7d59db9@amazon.com>
 
 
 
 <4741eceb3beb40c2bc82613c67836d66@amazon.com>
 
Message-ID: 

To try to loop back on my original point...

The "underlying problem" that I think should be addressed by some new
internal class (or suite of classes) is the "array builder" problem. This
is where you're doing "append, append, append, ..., use read-only
thereafter".

Currently people use ArrayList for that, or for primitive arrays, homebrew
it with System.arraycopy() - or maybe I'm missing something like this that
already exists?

I would like to see JDK standard "array builders" for primitive types and
reference types that use fixed sized (power-of-two) segments internally.
These can be internal classes for now.

Then the faster ByteArrayOutputStream becomes just a wrapper around
"ByteArrayBuilder" or whatever we call it.

This is all just my opinion, I'm curious if others perceive the same gap
that I do?

-Archie


On Fri, Apr 11, 2025 at 10:15?AM Archie Cobbs 
wrote:

> On Fri, Apr 11, 2025 at 8:11?AM Engebretson, John 
> wrote:
>
>> It seems like a good general-purpose list but I wouldn?t recommend it as
>> a direct replacement for either ArrayList or LinkedList; in the former case
>> the risk is slower random accesses, and in the latter the risk is to head
>> modifications.
>>
>
> Interesting results. However I don't think comparing this to both
> ArrayList and LinkedList is really fair. Developers choose an
> implementation based on how they know they are going to use it: If they are
> just adding stuff, they choose ArrayList. If they know they need to
> insert/remove in the middle, they choose LinkedList. If they need to
> add/remove from both ends, they choose ArrayDeque. Etc.
>
> So the optimal design changes depending on which "flavor" of list usage
> the developer is implying when they choose some implementation class.
>
> E.g., if you wanted to target the "ArrayList flavor', then you'd use fixed
> size, power-of-two segments. Then get() remains constant time, and insert
> and remove remain as painfully slow as ever, but the common "list builder"
> usage pattern of "append, append, append, ..., use read-only thereafter"
> gets a lot faster.
>
> OTOH variable-sized chunks makes lots of sense for the "LinkedList"
> flavor. In fact you could have a LinkedList that just uses an
> ArrayList> internally :)
>
> -Archie
>
> --
> Archie L. Cobbs
>


-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jengebr at amazon.com  Fri Apr 11 15:50:03 2025
From: jengebr at amazon.com (Engebretson, John)
Date: Fri, 11 Apr 2025 15:50:03 +0000
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: 
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 
 <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 
 
 <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
 
 <3f1c69a7ac5946809d2af850d7d59db9@amazon.com>
 
 
 
 <4741eceb3beb40c2bc82613c67836d66@amazon.com>
 
 
Message-ID: <95335d21438d4826a87db616b65d9ec9@amazon.com>

I would like to see JDK standard "array builders" for primitive types and reference types that use fixed sized (power-of-two) segments internally.

I want to caution on the power-of-two idea ? it leads to large objects faster than the current implementation, which hurts performance as well as max capacity.  There is value in fixed-size options but we would want something with a slower rate of growth.

The "underlying problem" that I think should be addressed by some new internal class (or suite of classes) is the "array builder" problem. This is where you're doing "append, append, append, ..., use read-only thereafter".

I would prefer targeting a few, common use cases ? ByteArrayOutputStream is the example that got us here. Optimizing forward-only handling is an easy starting place and we can always add on later.
    John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From j3graham at gmail.com  Fri Apr 11 16:15:50 2025
From: j3graham at gmail.com (Johannes Graham)
Date: Fri, 11 Apr 2025 12:15:50 -0400
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: 
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 
 <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 
 
 <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
 
 <3f1c69a7ac5946809d2af850d7d59db9@amazon.com>
 
 
 
 <4741eceb3beb40c2bc82613c67836d66@amazon.com>
 
 
Message-ID: 

There is one form of array builder already in the JDK - Stream.builder().
This doesn't cover off all of the use-cases, but covers some of them
(notably not the byte array case).

-Johannes



On Fri, Apr 11, 2025 at 11:47?AM Archie Cobbs 
wrote:

> To try to loop back on my original point...
>
> The "underlying problem" that I think should be addressed by some new
> internal class (or suite of classes) is the "array builder" problem. This
> is where you're doing "append, append, append, ..., use read-only
> thereafter".
>
> Currently people use ArrayList for that, or for primitive arrays, homebrew
> it with System.arraycopy() - or maybe I'm missing something like this that
> already exists?
>
> I would like to see JDK standard "array builders" for primitive types and
> reference types that use fixed sized (power-of-two) segments internally.
> These can be internal classes for now.
>
> Then the faster ByteArrayOutputStream becomes just a wrapper around
> "ByteArrayBuilder" or whatever we call it.
>
> This is all just my opinion, I'm curious if others perceive the same gap
> that I do?
>
> -Archie
>
>
> On Fri, Apr 11, 2025 at 10:15?AM Archie Cobbs 
> wrote:
>
>> On Fri, Apr 11, 2025 at 8:11?AM Engebretson, John 
>> wrote:
>>
>>> It seems like a good general-purpose list but I wouldn?t recommend it as
>>> a direct replacement for either ArrayList or LinkedList; in the former case
>>> the risk is slower random accesses, and in the latter the risk is to head
>>> modifications.
>>>
>>
>> Interesting results. However I don't think comparing this to both
>> ArrayList and LinkedList is really fair. Developers choose an
>> implementation based on how they know they are going to use it: If they are
>> just adding stuff, they choose ArrayList. If they know they need to
>> insert/remove in the middle, they choose LinkedList. If they need to
>> add/remove from both ends, they choose ArrayDeque. Etc.
>>
>> So the optimal design changes depending on which "flavor" of list usage
>> the developer is implying when they choose some implementation class.
>>
>> E.g., if you wanted to target the "ArrayList flavor', then you'd use
>> fixed size, power-of-two segments. Then get() remains constant time, and
>> insert and remove remain as painfully slow as ever, but the common "list
>> builder" usage pattern of "append, append, append, ..., use read-only
>> thereafter" gets a lot faster.
>>
>> OTOH variable-sized chunks makes lots of sense for the "LinkedList"
>> flavor. In fact you could have a LinkedList that just uses an
>> ArrayList> internally :)
>>
>> -Archie
>>
>> --
>> Archie L. Cobbs
>>
>
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From archie.cobbs at gmail.com  Fri Apr 11 16:19:11 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 11 Apr 2025 11:19:11 -0500
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: <95335d21438d4826a87db616b65d9ec9@amazon.com>
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 
 <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 
 
 <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
 
 <3f1c69a7ac5946809d2af850d7d59db9@amazon.com>
 
 
 
 <4741eceb3beb40c2bc82613c67836d66@amazon.com>
 
 
 <95335d21438d4826a87db616b65d9ec9@amazon.com>
Message-ID: 

On Fri, Apr 11, 2025 at 10:50?AM Engebretson, John 
wrote:

> I would like to see JDK standard "array builders" for primitive types and
> reference types that use fixed sized (power-of-two) segments internally.
>
>
>
> I want to caution on the power-of-two idea ? it leads to large objects
> faster than the current implementation, which hurts performance as well as
> max capacity.  There is value in fixed-size options but we would want
> something with a slower rate of growth.
>

Sorry if that wasn't clear - I didn't mean power-of-two exponential growth,
I meant all segments were literally fixed size, like 256 or something (or
maybe this value would be provided to the constructor). This keeps the
access to individual elements constant time.


>
>
> The "underlying problem" that I think should be addressed by some new
> internal class (or suite of classes) is the "array builder" problem. This
> is where you're doing "append, append, append, ..., use read-only
> thereafter".
>
>
>
> I would prefer targeting a few, common use cases ? ByteArrayOutputStream
> is the example that got us here. Optimizing forward-only handling is an
> easy starting place and we can always add on later.
>

Fair enough - my idea is independent in the sense that it could be done
later and then retrofitted.

So I think I should probably go off and think about it more and stop
hijacking your thread :)

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jengebr at amazon.com  Fri Apr 11 17:01:26 2025
From: jengebr at amazon.com (Engebretson, John)
Date: Fri, 11 Apr 2025 17:01:26 +0000
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: 
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 
 <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 
 
 <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
 
 <3f1c69a7ac5946809d2af850d7d59db9@amazon.com>
 
 
 
 <4741eceb3beb40c2bc82613c67836d66@amazon.com>
 
 
 
Message-ID: <4c4aac5737d844a4959885c65f17efee@amazon.com>

There is one form of array builder already in the JDK - Stream.builder(). This doesn't cover off all of the use-cases, but covers some of them (notably not the byte array case).

Thanks for pointing that out!  Under-the-covers it relies on java.util.stream.SpinedBuffer, which is built on the same type of segmented structure I suggested.  There are some differences and I need to measure some of the performance aspects, but it is definitely aimed at the same type of problem.
    John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kcr at openjdk.org  Fri Apr 11 18:43:28 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Apr 2025 18:43:28 GMT
Subject: RFR: 8254622: Hide superclasses from conditionally exported
 packages [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 8 Apr 2025 09:02:25 GMT, Hannes Walln?fer  wrote:

>> Please review an enhancement to treat classes and interfaces that are not included and not unconditionally exported as hidden. This means they do not show up in the generated documentation even if they are implemented or extended by a documented type. 
>> 
>> This change makes the `@hidden` JavaDoc tag unnecessary in two internal base classes that previously used it, `jdk.internal.vm.vector.VectorSupport` and `jdk.internal.event.Event`. The generated documentation is unchanged.
>> 
>> The change also adds support for the `@hidden` JavaDoc tag in interfaces, which was previously missing, and adds coverage to `TestHiddenTag.java`.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback: add Utils.isVisible(TypeElement) method

I didn't review the code changes, but I did test this by building the JDK with this fix and using the javadoc tool from that JDK to build the JavaFX docs. The non-exported intermediate classes that we currently see (without this PR) in the class hierarchy are now elided from the docs as expected.

-------------

Marked as reviewed by kcr (Author).

PR Review: https://git.openjdk.org/jdk/pull/24446#pullrequestreview-2761262117

From liach at openjdk.org  Fri Apr 11 19:44:31 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Apr 2025 19:44:31 GMT
Subject: RFR: 8254622: Hide superclasses from conditionally exported
 packages [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 8 Apr 2025 09:02:25 GMT, Hannes Walln?fer  wrote:

>> Please review an enhancement to treat classes and interfaces that are not included and not unconditionally exported as hidden. This means they do not show up in the generated documentation even if they are implemented or extended by a documented type. 
>> 
>> This change makes the `@hidden` JavaDoc tag unnecessary in two internal base classes that previously used it, `jdk.internal.vm.vector.VectorSupport` and `jdk.internal.event.Event`. The generated documentation is unchanged.
>> 
>> The change also adds support for the `@hidden` JavaDoc tag in interfaces, which was previously missing, and adds coverage to `TestHiddenTag.java`.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback: add Utils.isVisible(TypeElement) method

The new isHidden utility looks good. Sorry for a late review.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24446#pullrequestreview-2761437931

From almatvee at openjdk.org  Fri Apr 11 20:02:28 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 11 Apr 2025 20:02:28 GMT
Subject: RFR: 8354320: Changes to jpackage.md cause pandoc warning [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 13:50:04 GMT, Alexey Semenyuk  wrote:

>> Escape the dollar sign.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable tex_math_dollars extension

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24585#pullrequestreview-2761465832

From bchristi at openjdk.org  Fri Apr 11 20:09:10 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 11 Apr 2025 20:09:10 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v5]
In-Reply-To: 
References: 
Message-ID: 

> Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead to intermittent test failures ([JDK-8298783](https://bugs.openjdk.org/browse/JDK-8298783)  is a recent example).
> 
> A better mechanism already exists in the private `Reference.waitForReferenceProcessing()` method. This PR makes `waitForReferenceProcessing()` available to tests via the `WhiteBox` and `ForceGC` test libraries.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  wFRP throws InterruptedException, pass through from InvocationTargetException; don't check param count

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24527/files
  - new: https://git.openjdk.org/jdk/pull/24527/files/8aa0595a..58191e86

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24527&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24527&range=03-04

  Stats: 9 lines in 1 file changed: 7 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24527/head:pull/24527

PR: https://git.openjdk.org/jdk/pull/24527

From bchristi at openjdk.org  Fri Apr 11 20:12:25 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 11 Apr 2025 20:12:25 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v3]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <4HJ_-apaWG7HKYdg5Jr-xBOCv1VNwWWakXvnfpvzxjs=.db51dcb0-6639-4fea-8497-4a5ac9faddf0@github.com>

On Fri, 11 Apr 2025 02:25:20 GMT, Stuart Marks  wrote:

>> I disagree. IMO, for a test library, it's an unnecessary burden to make callers catch a checked exception.
>
> Hm. In general, if something blocks interruptibly, it should be declared to throw InterruptedException instead of catching and rethrowing something of another exception type. We should look at the use sites to be sure, but it's generally not an inconvenience for tests to deal with checked exceptions; it's perfectly acceptable for them to declare `throws InterruptedException` or even `throws Exception` and let the framework handle the exception if the test itself doesn't want to.

Thanks, Stuart. I've updated the new method to throw `InterruptedException`, and pass the exception from `InvocationTargetException` on through.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2040243940

From bchristi at openjdk.org  Fri Apr 11 20:17:26 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 11 Apr 2025 20:17:26 GMT
Subject: RFR: 8354335: No longer deprecate wrapper class constructors for
 removal
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Apr 2025 22:05:04 GMT, Roger Riggs  wrote:

> Remove forRemoval = true from @Deprecated annotation of Boolean, Byte, Character, Double, Float, Integer, Long, Short.
> And add `SuppressWarnings("deprecation") `where needed; and remove `SuppressWarnings("removal")`

LGTM

-------------

Marked as reviewed by bchristi (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24586#pullrequestreview-2761490305

From iris at openjdk.org  Fri Apr 11 20:24:25 2025
From: iris at openjdk.org (Iris Clark)
Date: Fri, 11 Apr 2025 20:24:25 GMT
Subject: RFR: 8354335: No longer deprecate wrapper class constructors for
 removal
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Apr 2025 22:05:04 GMT, Roger Riggs  wrote:

> Remove forRemoval = true from @Deprecated annotation of Boolean, Byte, Character, Double, Float, Integer, Long, Short.
> And add `SuppressWarnings("deprecation") `where needed; and remove `SuppressWarnings("removal")`

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24586#pullrequestreview-2761501284

From vlivanov at openjdk.org  Fri Apr 11 21:23:52 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 11 Apr 2025 21:23:52 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v5]
In-Reply-To: 
References: 
Message-ID: 

> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
> 
> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
> 
> The patch consists of the following parts:
>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
> 
> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
> 
> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
> 
> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
> 
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
> 
> Thanks!

Vladimir Ivanov 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 19 additional commits since the last revision:

 - Merge branch 'master' into vector.math.01.java
 - RVV and SVE adjustments
 - Merge branch 'master' into vector.math.01.java
 - Fix windows-aarch64 build failure
 - features_string -> cpu_info_string
 - Reviews and Float64Vector-related fix
 - Misc fixes and cleanups
 - CPU features support
 - Cleanup
 - TODO list
 - ... and 9 more: https://git.openjdk.org/jdk/compare/4aed10ed...0ffed12f

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24462/files
  - new: https://git.openjdk.org/jdk/pull/24462/files/bb1a11db..0ffed12f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=03-04

  Stats: 43013 lines in 720 files changed: 22287 ins; 17599 del; 3127 mod
  Patch: https://git.openjdk.org/jdk/pull/24462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24462/head:pull/24462

PR: https://git.openjdk.org/jdk/pull/24462

From rriggs at openjdk.org  Fri Apr 11 21:30:36 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 11 Apr 2025 21:30:36 GMT
Subject: RFR: 8354053: Remove unused JavaIOFilePermissionAccess
Message-ID: 

The JavaIOFilePermissionAccess interface is removed from SharedSecrets and its implementation (FilePermCompat.java) used by the test is moved to java.io FilePermission where cross package access is not needed. 
The test FilePermissionCollectionMerge is updated to access the internal implementation in FilePermission. 
Modernized the initialization from the system property `jdk.io.permissionsUseCanonicalPath`. 
The remaining support will be removed when FilePermission is removed.

-------------

Commit messages:
 - 8354053: Remove unused JavaIOFilePermissionAccess

Changes: https://git.openjdk.org/jdk/pull/24603/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24603&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354053
  Stats: 262 lines in 5 files changed: 59 ins; 176 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/24603.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24603/head:pull/24603

PR: https://git.openjdk.org/jdk/pull/24603

From ihse at openjdk.org  Fri Apr 11 21:31:30 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 11 Apr 2025 21:31:30 GMT
Subject: RFR: 8354320: Changes to jpackage.md cause pandoc warning [v3]
In-Reply-To: 
References: 
 
Message-ID: <03GKJ4rPRbeoh8w_8nsdHHMrSxbCooMzpCAeXFtS0Dk=.8de0c216-6e82-4760-9788-6f6198f3e932@github.com>

On Fri, 11 Apr 2025 13:50:04 GMT, Alexey Semenyuk  wrote:

>> Escape the dollar sign.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable tex_math_dollars extension

Maybe wait for someone else to review the build change too...

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24585#pullrequestreview-2761605007

From rriggs at openjdk.org  Fri Apr 11 21:39:26 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 11 Apr 2025 21:39:26 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 20:09:10 GMT, Brent Christian  wrote:

>> Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead to intermittent test failures ([JDK-8298783](https://bugs.openjdk.org/browse/JDK-8298783)  is a recent example).
>> 
>> A better mechanism already exists in the private `Reference.waitForReferenceProcessing()` method. This PR makes `waitForReferenceProcessing()` available to tests via the `WhiteBox` and `ForceGC` test libraries.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wFRP throws InterruptedException, pass through from InvocationTargetException; don't check param count

test/lib/jdk/test/whitebox/WhiteBox.java line 568:

> 566:   private Method getWaitForReferenceProcessingMethod() {
> 567:     Method wfrp = waitForReferenceProcessingMethod;
> 568:     if (wfrp == null) {

Racy initialization is fine, the field can be static and the last one (any racy init would all the same) wins:
Suggestion:

  private static Method waitForReferenceProcessingMethod = getWaitForReferenceProcessingMethod();

  private static Method getWaitForReferenceProcessingMethod() {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2040327180

From asemenyuk at openjdk.org  Fri Apr 11 22:38:26 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 11 Apr 2025 22:38:26 GMT
Subject: RFR: 8354320: Changes to jpackage.md cause pandoc warning [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 13:50:04 GMT, Alexey Semenyuk  wrote:

>> Escape the dollar sign.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable tex_math_dollars extension

@erikj79 PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24585#issuecomment-2798123318

From liach at openjdk.org  Fri Apr 11 22:49:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Apr 2025 22:49:37 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures while
 jdeps in JDK 22 works fine
Message-ID: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>

When jdeps was migrated from old classfile to ClassFile API, the parsing semantic changed - error checks are now made lazily, and nested crashes from malformed signature or other problems is now latent, after a `ClassModel` instance is available. (The old error check existed only for constructing a `ClassModel`)

To address this issue, I have updated the way of iterating class files to be handler/consumer based like in the ClassFile API. This has the advantage that when one invocation of the handler fails of a `ClassFileError`, other invocations for other class files can proceed, and the exception handler has sufficient information to report a useful message indicating the source of error.

For the particular example of examining a proguard processed `dummy-scala.jar`, here is the new output of `jdeps dummy-scala.jar`:

Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 59, expected an identifier: Lscala/collection/immutable/TreeMap$TreeMapBuilder.;: scala/collection/immutable/TreeMap$TreeMapBuilder.class (dummy-scala.jar)
Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 49, expected an identifier: Lscala/collection/parallel/mutable/ParArray.;: scala/collection/parallel/mutable/ParArray.class (dummy-scala.jar)


Now, jdeps shows the bad class files. Inspection into the files reveal that proguard incorrectly deleted the simple class names with trailing `$`, for example, the original signature of the broken ParArray was `Lscala/collection/parallel/mutable/ParArray.ParArrayIterator$;`, so the `ParArrayIterator$` part was incorrectly dropped by proguard.

Testing: langtools/tools/jdeps.

-------------

Commit messages:
 - 8341608: jdeps in JDK 23 crashes when parsing signatures while jdeps in JDK 22 works fine

Changes: https://git.openjdk.org/jdk/pull/24604/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24604&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341608
  Stats: 167 lines in 3 files changed: 16 ins; 106 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/24604.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24604/head:pull/24604

PR: https://git.openjdk.org/jdk/pull/24604

From joehw at openjdk.org  Fri Apr 11 23:11:01 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 11 Apr 2025 23:11:01 GMT
Subject: RFR: 8354084: Streamline XPath API's extension function control
Message-ID: <2h00m7NTlmM0pu-x7bRU7_UfgKkS2WVJ4jUEF3hnkzo=.a48773d0-d6e6-4505-8511-76902957b9eb@github.com>

Streamline the extension function control in the XPath API by relying solely on [XPathFunctionResolver](https://docs.oracle.com/en/java/javase/24/docs/api/java.xml/javax/xml/xpath/XPathFunctionResolver.html), which provides a secure and developer-defined mechanism. Remove the feature FEATURE_SECURE_PROCESSING and jdk.xml.enableExtensionFunctions from the decision path that are redundant with regard to XPath's Extension Functions.

Note the comment in JAXPExtensionsProvider, starting at  "JAXP 1.3 spec says When ...", was not accurate. Refer to the spec: https://docs.oracle.com/en/java/javase/24/docs/api/java.xml/javax/xml/XMLConstants.html#FEATURE_SECURE_PROCESSING, FSP does not have specific requirement for the XPath functions.

Tests:
    Tier1 - 3 passed with regard to this change. There were unrelated/known failures (e.g. bug8329757).
    JCK passed except the previously reported issue (JCK-7322355).

-------------

Commit messages:
 - 8354084: Streamline XPath API's extension function control

Changes: https://git.openjdk.org/jdk/pull/24605/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24605&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354084
  Stats: 516 lines in 19 files changed: 185 ins; 301 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/24605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24605/head:pull/24605

PR: https://git.openjdk.org/jdk/pull/24605

From bchristi at openjdk.org  Fri Apr 11 23:31:16 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 11 Apr 2025 23:31:16 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v6]
In-Reply-To: 
References: 
Message-ID: 

> Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead to intermittent test failures ([JDK-8298783](https://bugs.openjdk.org/browse/JDK-8298783)  is a recent example).
> 
> A better mechanism already exists in the private `Reference.waitForReferenceProcessing()` method. This PR makes `waitForReferenceProcessing()` available to tests via the `WhiteBox` and `ForceGC` test libraries.

Brent Christian has updated the pull request incrementally with two additional commits since the last revision:

 - Make *the method* static, also
 - Make Method static

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24527/files
  - new: https://git.openjdk.org/jdk/pull/24527/files/58191e86..e47caf5a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24527&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24527&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24527/head:pull/24527

PR: https://git.openjdk.org/jdk/pull/24527

From bchristi at openjdk.org  Fri Apr 11 23:31:16 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 11 Apr 2025 23:31:16 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v5]
In-Reply-To: 
References: 
 
 
Message-ID: <9UyK1s82KL1F08bETPEV0i_xODM6fuJoPes16Bjy5y4=.032b9b80-d5de-4ec8-99ac-ab5d39eaab4d@github.com>

On Fri, 11 Apr 2025 21:36:28 GMT, Roger Riggs  wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   wFRP throws InterruptedException, pass through from InvocationTargetException; don't check param count
>
> test/lib/jdk/test/whitebox/WhiteBox.java line 568:
> 
>> 566:   private Method getWaitForReferenceProcessingMethod() {
>> 567:     Method wfrp = waitForReferenceProcessingMethod;
>> 568:     if (wfrp == null) {
> 
> Racy initialization is fine, the field can be static and the last one (any racy init would all the same) wins:
> Suggestion:
> 
>   private static Method waitForReferenceProcessingMethod = getWaitForReferenceProcessingMethod();
> 
>   private static Method getWaitForReferenceProcessingMethod() {

I can make the `Method` static, but I don't think it should be set until there's a call to `getWaitForReferenceProcessing()`, as most uses of `WhiteBox` won't need it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2040420062

From joehw at openjdk.org  Sat Apr 12 00:08:26 2025
From: joehw at openjdk.org (Joe Wang)
Date: Sat, 12 Apr 2025 00:08:26 GMT
Subject: RFR: 8354084: Streamline XPath API's extension function control
 [v2]
In-Reply-To: <2h00m7NTlmM0pu-x7bRU7_UfgKkS2WVJ4jUEF3hnkzo=.a48773d0-d6e6-4505-8511-76902957b9eb@github.com>
References: <2h00m7NTlmM0pu-x7bRU7_UfgKkS2WVJ4jUEF3hnkzo=.a48773d0-d6e6-4505-8511-76902957b9eb@github.com>
Message-ID: <7tVDaglZEzcHa0qOqOVMP3O8O-zrXdgdZXUO45HoKqc=.2190d577-aef1-481f-9060-58ab2e162cd2@github.com>

> Streamline the extension function control in the XPath API by relying solely on [XPathFunctionResolver](https://docs.oracle.com/en/java/javase/24/docs/api/java.xml/javax/xml/xpath/XPathFunctionResolver.html), which provides a secure and developer-defined mechanism. Remove the feature FEATURE_SECURE_PROCESSING and jdk.xml.enableExtensionFunctions from the decision path that are redundant with regard to XPath's Extension Functions.
> 
> Note the comment in JAXPExtensionsProvider, starting at  "JAXP 1.3 spec says When ...", was not accurate. Refer to the spec: https://docs.oracle.com/en/java/javase/24/docs/api/java.xml/javax/xml/XMLConstants.html#FEATURE_SECURE_PROCESSING, FSP does not have specific requirement for the XPath functions.
> 
> Tests:
>     Tier1 - 3 passed with regard to this change. There were unrelated/known failures (e.g. bug8329757).
>     JCK passed except the previously reported issue (JCK-7322355).

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  add copyright and docs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24605/files
  - new: https://git.openjdk.org/jdk/pull/24605/files/f27712fc..72c138f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24605&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24605&range=00-01

  Stats: 26 lines in 1 file changed: 25 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24605/head:pull/24605

PR: https://git.openjdk.org/jdk/pull/24605

From kbarrett at openjdk.org  Sat Apr 12 05:33:31 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 12 Apr 2025 05:33:31 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v5]
In-Reply-To: <9UyK1s82KL1F08bETPEV0i_xODM6fuJoPes16Bjy5y4=.032b9b80-d5de-4ec8-99ac-ab5d39eaab4d@github.com>
References: 
 
 
 <9UyK1s82KL1F08bETPEV0i_xODM6fuJoPes16Bjy5y4=.032b9b80-d5de-4ec8-99ac-ab5d39eaab4d@github.com>
Message-ID: <9GeDYcF8iNiazR59SkveA_bTx7aFqYXr1lEeR2L_QHw=.faec08ad-7b1b-4729-b352-763f32ccb52d@github.com>

On Fri, 11 Apr 2025 23:26:45 GMT, Brent Christian  wrote:

>> test/lib/jdk/test/whitebox/WhiteBox.java line 568:
>> 
>>> 566:   private Method getWaitForReferenceProcessingMethod() {
>>> 567:     Method wfrp = waitForReferenceProcessingMethod;
>>> 568:     if (wfrp == null) {
>> 
>> Racy initialization is fine, the field can be static and the last one (any racy init would all the same) wins:
>> Suggestion:
>> 
>>   private static Method waitForReferenceProcessingMethod = getWaitForReferenceProcessingMethod();
>> 
>>   private static Method getWaitForReferenceProcessingMethod() {
>
> I can make the `Method` static, but I don't think it should be set until there's a call to `getWaitForReferenceProcessing()`, as most uses of `WhiteBox` won't need it.

Not only will most uses of `WhiteBox` not need it, but those uses would be "broken" because they would
be forced to (without benefit) add the `@modules` declaration needed to allow that to work.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2040569359

From kbarrett at openjdk.org  Sat Apr 12 05:50:33 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 12 Apr 2025 05:50:33 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 23:31:16 GMT, Brent Christian  wrote:

>> Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead to intermittent test failures ([JDK-8298783](https://bugs.openjdk.org/browse/JDK-8298783)  is a recent example).
>> 
>> A better mechanism already exists in the private `Reference.waitForReferenceProcessing()` method. This PR makes `waitForReferenceProcessing()` available to tests via the `WhiteBox` and `ForceGC` test libraries.
>
> Brent Christian has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Make *the method* static, also
>  - Make Method static

Changes requested by kbarrett (Reviewer).

test/lib/jdk/test/whitebox/WhiteBox.java line 609:

> 607:       throw e;
> 608:     } catch (Throwable t) {
> 609:       throw new RuntimeException(t);

The only checked exceptions that are thrown by the try-body are `InvocationTargetException` and
`IllegalAccessException` (both from `Method::invoke`).  The way `InvocationTargetException` is being
handled here seems fine.  But I think it would be better to explicitly handle `IllegalAccessException` and
transform it into a `RuntimeException`, and let everything else just propagate out untouched, e.g. no
handlers for `RuntimeException` or `Throwable`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24527#pullrequestreview-2762068601
PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2040574823

From alanb at openjdk.org  Sat Apr 12 05:51:33 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 12 Apr 2025 05:51:33 GMT
Subject: RFR: 8343157: Examine large files for character encoding/decoding
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Apr 2025 17:02:13 GMT, Naoto Sato  wrote:

> Removing old charset test cases that verify new charset implementations (as of JDK7). Removed tests/files are actual charset implementations used in pre-JDK7, which have been used for comparing the results. Since those "new" implementations have been used since then, I believe it is OK to retire those old test cases.

Okay to delete, no real value keeping these.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24597#pullrequestreview-2762069633

From alanb at openjdk.org  Sat Apr 12 05:53:31 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 12 Apr 2025 05:53:31 GMT
Subject: RFR: 8354320: Changes to jpackage.md cause pandoc warning [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 13:50:04 GMT, Alexey Semenyuk  wrote:

>> Escape the dollar sign.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable tex_math_dollars extension

Thanks for getting this to the right place.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24585#issuecomment-2798508458

From iklam at openjdk.org  Sat Apr 12 18:37:18 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 12 Apr 2025 18:37:18 GMT
Subject: RFR: 8352001: AOT cache should not contain classes injected into
 built-in class loaders [v2]
In-Reply-To: 
References: 
Message-ID: <8E5mTxKlKyx63Zm9-O7pvcpCEQWuXuB_BPyeWqhY0u8=.91c08221-3f6b-4e08-996c-444602f3a456@github.com>

> During an application's training run, it's possible to inject classes into the built-in platform/app class loaders with reflection calls. 
> 
> - Before [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), only the names of these classes were recorded in the AOT config file. When the AOT cache is generated, these classes are automatically filtered out.
> - Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), these classes are stored as parsed InstanceKlasses in the AOT config file, and will be transferred into the AOT cache. This new behavior may cause some applications to fail, as they may inject bytecodes that have environment dependencies.
> 
> For safety, this PR filters out such injected classes from the AOT config file.

Ioi Lam 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 'master' into 8352001-exclude-injected-classes-from-builtin-loaders
 - 8352001: AOT cache should not contain classes injected into built-in class loaders

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24046/files
  - new: https://git.openjdk.org/jdk/pull/24046/files/b5c177ee..23327c27

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24046&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24046&range=00-01

  Stats: 140748 lines in 3209 files changed: 61368 ins; 65475 del; 13905 mod
  Patch: https://git.openjdk.org/jdk/pull/24046.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24046/head:pull/24046

PR: https://git.openjdk.org/jdk/pull/24046

From liach at openjdk.org  Sun Apr 13 09:52:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 13 Apr 2025 09:52:38 GMT
Subject: Withdrawn: 8349716: IllegalAccessError when Proxy methods return
 object of a package-private type
In-Reply-To: <4f_LF0KVq5VErEt3iTND7-mgpfQv1OAloAnBQML6MJg=.da4c2f30-835d-489b-92b8-586830b66564@github.com>
References: <4f_LF0KVq5VErEt3iTND7-mgpfQv1OAloAnBQML6MJg=.da4c2f30-835d-489b-92b8-586830b66564@github.com>
Message-ID: 

On Tue, 11 Feb 2025 17:56:04 GMT, Chen Liang  wrote:

> The return value adaption of Proxy is problematic, that it may attempt to access package-private types inaccessible to its package in a `checkcast` instruction, which causes `IllegalAccessError` if the returned object is not `null`. This likely affects all Java versions since the publication of OpenJDK.
> 
> A practical effect of this is that if a repeatable annotation is package-private but the container is not, user code cannot access the `value` element in the container annotation.
> 
> All added tests except `PackagePrivateContainerTest::testGetRepeatable` fail on current mainline and pass with the ProxyGenerator patch.
> 
> Testing: Running tier 1-3

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/23567

From liach at openjdk.org  Sun Apr 13 10:10:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 13 Apr 2025 10:10:32 GMT
Subject: RFR: 8354053: Remove unused JavaIOFilePermissionAccess
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Apr 2025 21:26:08 GMT, Roger Riggs  wrote:

> The JavaIOFilePermissionAccess interface is removed from SharedSecrets and its implementation (FilePermCompat.java) used by the test is moved to java.io FilePermission where cross package access is not needed. 
> The test FilePermissionCollectionMerge is updated to access the internal implementation in FilePermission. 
> Modernized the initialization from the system property `jdk.io.permissionsUseCanonicalPath`. 
> The remaining support will be removed when FilePermission is removed.

src/java.base/share/classes/java/io/FilePermission.java line 254:

> 252: 
> 253:     // Construct a new Permission with altPath
> 254:     // Package private for use by test FilePermissionCollectionMerge

That test is already calling with reflection and +open, we can just make this private and non-static.

The last use of the original methods were removed when AccessControlContext was functionally removed. If security developers can check, maybe we can just remove these methods completely?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24603#discussion_r2041089794

From hannesw at openjdk.org  Sun Apr 13 10:11:33 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Sun, 13 Apr 2025 10:11:33 GMT
Subject: Integrated: 8254622: Hide superclasses from conditionally exported
 packages
In-Reply-To: 
References: 
Message-ID: <4FHbUdiOmwnhm63fitmIRgCo-EIzL3fhtwyzbF1ttEw=.4e6a260a-19f2-4dec-b046-62f8161233b2@github.com>

On Fri, 4 Apr 2025 13:36:19 GMT, Hannes Walln?fer  wrote:

> Please review an enhancement to treat classes and interfaces that are not included and not unconditionally exported as hidden. This means they do not show up in the generated documentation even if they are implemented or extended by a documented type. 
> 
> This change makes the `@hidden` JavaDoc tag unnecessary in two internal base classes that previously used it, `jdk.internal.vm.vector.VectorSupport` and `jdk.internal.event.Event`. The generated documentation is unchanged.
> 
> The change also adds support for the `@hidden` JavaDoc tag in interfaces, which was previously missing, and adds coverage to `TestHiddenTag.java`.

This pull request has now been integrated.

Changeset: 5d976089
Author:    Hannes Walln?fer 
URL:       https://git.openjdk.org/jdk/commit/5d9760897014c9a2cf0813af3ffbfb358ef55e31
Stats:     436 lines in 21 files changed: 352 ins; 29 del; 55 mod

8254622: Hide superclasses from conditionally exported packages

Reviewed-by: kcr, liach

-------------

PR: https://git.openjdk.org/jdk/pull/24446

From liach at openjdk.org  Sun Apr 13 15:54:22 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 13 Apr 2025 15:54:22 GMT
Subject: RFR: 8349716: IllegalAccessError when Proxy methods return object of a
 package-private type
Message-ID: <9yD4li2CQ0XdnS4VGoa4udyr_8M7rvFU-jYjeigSu_I=.8b525314-a566-48f0-bcf5-27fd72c14bfb@github.com>

Proxy currently places proxy classes that proxy interfaces with package-private return types in dynamic modules. This means that if a return value is non-null, Proxy cannot return it and throws IllegalAccessError.

This patch changes strategy so proxy classes for any reference to package-private types (in parameter or return) are now considered as package-private, tightening the restrictions on proxy factories.

-------------

Commit messages:
 - Update test/jdk/java/lang/annotation/WithPackagePrivateTest.java
 - Make package private if any referenced type is
 - Test suite

Changes: https://git.openjdk.org/jdk/pull/24611/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24611&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349716
  Stats: 393 lines in 10 files changed: 274 ins; 53 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/24611.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24611/head:pull/24611

PR: https://git.openjdk.org/jdk/pull/24611

From duke at openjdk.org  Sun Apr 13 15:54:23 2025
From: duke at openjdk.org (Hendrik Schick)
Date: Sun, 13 Apr 2025 15:54:23 GMT
Subject: RFR: 8349716: IllegalAccessError when Proxy methods return object
 of a package-private type
In-Reply-To: <9yD4li2CQ0XdnS4VGoa4udyr_8M7rvFU-jYjeigSu_I=.8b525314-a566-48f0-bcf5-27fd72c14bfb@github.com>
References: <9yD4li2CQ0XdnS4VGoa4udyr_8M7rvFU-jYjeigSu_I=.8b525314-a566-48f0-bcf5-27fd72c14bfb@github.com>
Message-ID: 

On Sun, 13 Apr 2025 09:49:46 GMT, Chen Liang  wrote:

> Proxy currently places proxy classes that proxy interfaces with package-private return types in dynamic modules. This means that if a return value is non-null, Proxy cannot return it and throws IllegalAccessError.
> 
> This patch changes strategy so proxy classes for any reference to package-private types (in parameter or return) are now considered as package-private, tightening the restrictions on proxy factories.

test/jdk/java/lang/annotation/WithPackagePrivateTest.java line 44:

> 42: 
> 43: /**
> 44:  * Test public annotations that has elements of package-private types.

Suggestion:

 * Test public annotations that have elements of package-private types.

test/jdk/java/lang/reflect/Proxy/NonPublicMethodTypeTest.java line 1:

> 1: /*

update copyright to 2025 aswell

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24611#discussion_r2041144035
PR Review Comment: https://git.openjdk.org/jdk/pull/24611#discussion_r2041144939

From liach at openjdk.org  Sun Apr 13 16:07:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 13 Apr 2025 16:07:30 GMT
Subject: RFR: 8349716: IllegalAccessError when Proxy methods return object
 of a package-private type
In-Reply-To: <9yD4li2CQ0XdnS4VGoa4udyr_8M7rvFU-jYjeigSu_I=.8b525314-a566-48f0-bcf5-27fd72c14bfb@github.com>
References: <9yD4li2CQ0XdnS4VGoa4udyr_8M7rvFU-jYjeigSu_I=.8b525314-a566-48f0-bcf5-27fd72c14bfb@github.com>
Message-ID: 

On Sun, 13 Apr 2025 09:49:46 GMT, Chen Liang  wrote:

> Proxy currently places proxy classes that proxy interfaces with package-private return types in dynamic modules. This means that if a return value is non-null, Proxy cannot return it and throws IllegalAccessError.
> 
> This patch changes strategy so proxy classes for any reference to package-private types (in parameter or return) are now considered as package-private, tightening the restrictions on proxy factories.

Testing: tier 1-3 passed

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24611#issuecomment-2800010741

From alanb at openjdk.org  Sun Apr 13 17:40:23 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 13 Apr 2025 17:40:23 GMT
Subject: RFR: 8349716: IllegalAccessError when Proxy methods return object
 of a package-private type
In-Reply-To: <9yD4li2CQ0XdnS4VGoa4udyr_8M7rvFU-jYjeigSu_I=.8b525314-a566-48f0-bcf5-27fd72c14bfb@github.com>
References: <9yD4li2CQ0XdnS4VGoa4udyr_8M7rvFU-jYjeigSu_I=.8b525314-a566-48f0-bcf5-27fd72c14bfb@github.com>
Message-ID: 

On Sun, 13 Apr 2025 09:49:46 GMT, Chen Liang  wrote:

> Proxy currently places proxy classes that proxy interfaces with package-private return types in dynamic modules. This means that if a return value is non-null, Proxy cannot return it and throws IllegalAccessError.
> 
> This patch changes strategy so proxy classes for any reference to package-private types (in parameter or return) are now considered as package-private, tightening the restrictions on proxy factories.

I've set this PR to require at least 2 Reviewers, I think it will take time to work through and decide if the spec should be changed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24611#issuecomment-2800046785

From alanb at openjdk.org  Sun Apr 13 17:53:31 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 13 Apr 2025 17:53:31 GMT
Subject: RFR: 8354053: Remove unused JavaIOFilePermissionAccess
In-Reply-To: 
References: 
Message-ID: <8FEWzCYGGAof4_zU-rvI8YQViNAHnjS6ZEC9_o_r0jU=.104f0aa0-10c5-42b4-81c5-16ca577d55f6@github.com>

On Fri, 11 Apr 2025 21:26:08 GMT, Roger Riggs  wrote:

> The JavaIOFilePermissionAccess interface is removed from SharedSecrets and its implementation (FilePermCompat.java) used by the test is moved to java.io FilePermission where cross package access is not needed. 
> The test FilePermissionCollectionMerge is updated to access the internal implementation in FilePermission. 
> Modernized the initialization from the system property `jdk.io.permissionsUseCanonicalPath`. 
> The remaining support will be removed when FilePermission is removed.

@wangweij Is there any reason to keep the system property jdk.io.permissionsUseCanonicalPath ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24603#issuecomment-2800051496

From weijun at openjdk.org  Sun Apr 13 20:04:31 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Sun, 13 Apr 2025 20:04:31 GMT
Subject: RFR: 8354053: Remove unused JavaIOFilePermissionAccess
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Apr 2025 21:26:08 GMT, Roger Riggs  wrote:

> The JavaIOFilePermissionAccess interface is removed from SharedSecrets and its implementation (FilePermCompat.java) used by the test is moved to java.io FilePermission where cross package access is not needed. 
> The test FilePermissionCollectionMerge is updated to access the internal implementation in FilePermission. 
> Modernized the initialization from the system property `jdk.io.permissionsUseCanonicalPath`. 
> The remaining support will be removed when FilePermission is removed.

I remember the implies method of the file permission class depends on whether this system property is set. Although file permission is no longer used in access control check the class and the method is still there.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24603#issuecomment-2800101409

From ihse at openjdk.org  Sun Apr 13 22:50:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sun, 13 Apr 2025 22:50:37 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8
Message-ID: 

This is a WIP to move the JDK source code base to fully UTF-8, and to ensure tools knows about this.

-------------

Commit messages:
 - Fix flags for Windows
 - Mark java and native source code as utf-8
 - Don't convert properties files to iso-8859-1.
 - Tell tools we use utf-8
 - Replace iso-8859-1 encodings with utf-8 in source code
 - Explain reason for non-UTF-8 character in JDK_RCFLAGS

Changes: https://git.openjdk.org/jdk/pull/24574/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24574&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301971
  Stats: 130 lines in 8 files changed: 17 ins; 103 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/24574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24574/head:pull/24574

PR: https://git.openjdk.org/jdk/pull/24574

From ihse at openjdk.org  Sun Apr 13 22:58:26 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sun, 13 Apr 2025 22:58:26 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8
In-Reply-To: 
References: 
Message-ID: <0io2A_4xFMiR8rwbXPPyYyXar_fwE1jG4K81pY_heUU=.18d9f809-dafc-4900-82fa-6478eb50b8de@github.com>

On Thu, 10 Apr 2025 14:28:02 GMT, Magnus Ihse Bursie  wrote:

> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
> 
> The fix is basically simple, and includes the following steps:
> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).

I would like to run proper tests to verify the changes in libjava, but I don't know what tests that would be. If anyone can enlighten me, please do. 

(I suspect that the code did not really work properly before, and that the specially encoded characters where not thoroughly tested, but I can be wrong.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2800165519

From ihse at openjdk.org  Sun Apr 13 23:14:41 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sun, 13 Apr 2025 23:14:41 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
> 
> The fix is basically simple, and includes the following steps:
> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Also tell javadoc that we have utf-8 now

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24574/files
  - new: https://git.openjdk.org/jdk/pull/24574/files/4fb897ef..38004164

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24574&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24574&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24574/head:pull/24574

PR: https://git.openjdk.org/jdk/pull/24574

From alanb at openjdk.org  Mon Apr 14 12:50:43 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 14 Apr 2025 12:50:43 GMT
Subject: RFR: 8354053: Remove unused JavaIOFilePermissionAccess
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 13 Apr 2025 20:01:28 GMT, Weijun Wang  wrote:

> I remember the implies method of the file permission class depends on whether this system property is set. Although file permission is no longer used in access control check the class and the method are still there.

Right, and I wasn't suggesting we remove implies(FilePermission), instead I'm wondering if the compatibility knob and the implNote can be removed. As you know, it dates from the change to FilePermission in JDK 9 to do simple path matching rather than canonicalization.

In any case, I don't want to complicate Roger's cleanup, I'm just noting that it's doing cleanup on a compatibility property that we should have removed a few releases/years ago.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24603#issuecomment-2800552748

From kbarrett at openjdk.org  Mon Apr 14 12:51:33 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 14 Apr 2025 12:51:33 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sat, 12 Apr 2025 05:47:06 GMT, Kim Barrett  wrote:

>> Brent Christian has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Make *the method* static, also
>>  - Make Method static
>
> test/lib/jdk/test/whitebox/WhiteBox.java line 609:
> 
>> 607:       throw e;
>> 608:     } catch (Throwable t) {
>> 609:       throw new RuntimeException(t);
> 
> The only checked exceptions that are thrown by the try-body are `InvocationTargetException` and
> `IllegalAccessException` (both from `Method::invoke`).  The way `InvocationTargetException` is being
> handled here seems fine.  But I think it would be better to explicitly handle `IllegalAccessException` and
> transform it into a `RuntimeException`, and let everything else just propagate out untouched, e.g. no
> handlers for `RuntimeException` or `Throwable`.

Thinking about this some more, if we're going to extract and (re)throw
InterruptedException directly, then I prefer my earlier version:
https://github.com/openjdk/jdk/pull/24527#pullrequestreview-2755384786

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2041377443

From kbarrett at openjdk.org  Mon Apr 14 12:51:26 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 14 Apr 2025 12:51:26 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 23:31:16 GMT, Brent Christian  wrote:

>> Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead to intermittent test failures ([JDK-8298783](https://bugs.openjdk.org/browse/JDK-8298783)  is a recent example).
>> 
>> A better mechanism already exists in the private `Reference.waitForReferenceProcessing()` method. This PR makes `waitForReferenceProcessing()` available to tests via the `WhiteBox` and `ForceGC` test libraries.
>
> Brent Christian has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Make *the method* static, also
>  - Make Method static

Changes requested by kbarrett (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24527#pullrequestreview-2763075157

From duke at openjdk.org  Mon Apr 14 12:51:45 2025
From: duke at openjdk.org (kabutz)
Date: Mon, 14 Apr 2025 12:51:45 GMT
Subject: RFR: 8354111: JavaDoc states that Iterator.remove() is linear in
 the LinkedBlockingDeque
In-Reply-To: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
References: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
Message-ID: <5psF2REMXOqfIUUdp8D8dAlaXkvfFFsEyTUcnbYCRz4=.d6520d22-e35b-48e9-9204-14dc3c7d88a1@github.com>

On Tue, 8 Apr 2025 08:50:37 GMT, kabutz  wrote:

> One of the features of the LinkedBlockingDeque is that it is a doubly-linked node queue, with pointers in each node to "prev" and "next", which allows remove() in the Iterator to remove the node in constant time. However, in the JavaDoc of the class, it lists Iterator.remove() as an example of a method that takes linear time.

Joe Darcy has approved the CSR. Can we go ahead with integrating this PR? We might merge the other 4 PRs into a single one.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24500#issuecomment-2801504558

From fjiang at openjdk.org  Mon Apr 14 12:52:04 2025
From: fjiang at openjdk.org (Feilong Jiang)
Date: Mon, 14 Apr 2025 12:52:04 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 10:48:34 GMT, Hamlin Li  wrote:

>> Hi,
>> Can you help to review this patch?
>> On riscv, CMoveI/L already were implemented, but there are some gap:
>> 1. CMoveI/L does not support comparison with float/double, corresponding tests are not turn on either.
>> 2. Some optimization of C2 is not turned on, e.g. `Phi -> CMove -> min_max`.
>> 3. lack of some corresponding performance tests.
>> 
>> Also there are some issue with current Zicond:
>> 1. UseZicond is turned on automatically by hwprobe, but jmh tests show that it's not always bring benefit, in some situation it even brings regression, the reason is the generated code by Zicond is much larger than branch version, in particular when it's in a loop and unrolled.
>> 
>> This patch on riscv is to:
>> 1. add CMoveI/L comparing float/double, and corresponding tests,
>> 2. enable more C2 optimization,
>> 3. add more benchmark tests,
>> 4. turn off UseZicond by default.
>> 
>> Thanks!
>> 
>> ## Performance
>> 
>> ### MinMax
>> test data
>> 
>> Benchmark | Mode | Cnt | Score - master | Score - master+UseZbb | Score - -master+UseZicond | Score - master+UseZicond+UseZbb | Score - cmovei | Score - cmovei+UseZbb | Score - cmovei+UseZicond | Score - cmovei+UseZicond+UseZbb | Error | Units | Opt (master/cmovei)
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> o.o.b.vm.compiler.IfMinMax.testReductionInt | avgt | 40 | 17152.075 | 17216.592 | 17272.493 | 17296.89 | 17127.844 | 17036.605 | 17299.333 | 17250.566 | 73.179 | ns/op | 1.001
>> o.o.b.vm.compiler.IfMinMax.testReductionLong | avgt | 40 | 19770.828 | 19967.578 | 20268.905 | 20166.165 | 20065.552 | 20059.095 | 20161.914 | 20151.295 | 131.428 | ns/op | 0.985
>> o.o.b.vm.compiler.IfMinMax.testSingleInt | avgt | 40 | 114.734 | 114.402 | 114.887 | 114.384 | 114.4 | 110.631 | 112.162 | 110.915 | 0.333 | ns/op | 1.003
>> o.o.b.vm.compiler.IfMinMax.testSingleLong | avgt | 40 | 121.53 | 121.711 | 120.91 | 121.665 | 121.309 | 120.57 | 118.639 | 119.373 | 0.451 | ns/op | 1.002
>> o.o.b.vm.compiler.IfMinMax.testVectorInt | avgt | 40 | 60130.165 | 60062.303 | 61839.776 | 61895.194 | 15887.398 | 15924.502 | 15874.835 | 15667.936 | 101.94 | ns/op | 3.785
>> o.o.b.vm.c...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minors

Looks good. Thanks!

-------------

Marked as reviewed by fjiang (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24490#pullrequestreview-2763050383

From fyang at openjdk.org  Mon Apr 14 12:52:09 2025
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 14 Apr 2025 12:52:09 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L [v8]
In-Reply-To: 
References: 
 
Message-ID: <3i70nNWVi7q00e_Y7s5AfP2TdXtkWx79yuHPbFLWBLM=.a01717ba-c6fb-4f0d-a7e0-4b676fcce9bc@github.com>

On Fri, 11 Apr 2025 10:48:34 GMT, Hamlin Li  wrote:

>> Hi,
>> Can you help to review this patch?
>> On riscv, CMoveI/L already were implemented, but there are some gap:
>> 1. CMoveI/L does not support comparison with float/double, corresponding tests are not turn on either.
>> 2. Some optimization of C2 is not turned on, e.g. `Phi -> CMove -> min_max`.
>> 3. lack of some corresponding performance tests.
>> 
>> Also there are some issue with current Zicond:
>> 1. UseZicond is turned on automatically by hwprobe, but jmh tests show that it's not always bring benefit, in some situation it even brings regression, the reason is the generated code by Zicond is much larger than branch version, in particular when it's in a loop and unrolled.
>> 
>> This patch on riscv is to:
>> 1. add CMoveI/L comparing float/double, and corresponding tests,
>> 2. enable more C2 optimization,
>> 3. add more benchmark tests,
>> 4. turn off UseZicond by default.
>> 
>> Thanks!
>> 
>> ## Performance
>> 
>> ### MinMax
>> test data
>> 
>> Benchmark | Mode | Cnt | Score - master | Score - master+UseZbb | Score - -master+UseZicond | Score - master+UseZicond+UseZbb | Score - cmovei | Score - cmovei+UseZbb | Score - cmovei+UseZicond | Score - cmovei+UseZicond+UseZbb | Error | Units | Opt (master/cmovei)
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> o.o.b.vm.compiler.IfMinMax.testReductionInt | avgt | 40 | 17152.075 | 17216.592 | 17272.493 | 17296.89 | 17127.844 | 17036.605 | 17299.333 | 17250.566 | 73.179 | ns/op | 1.001
>> o.o.b.vm.compiler.IfMinMax.testReductionLong | avgt | 40 | 19770.828 | 19967.578 | 20268.905 | 20166.165 | 20065.552 | 20059.095 | 20161.914 | 20151.295 | 131.428 | ns/op | 0.985
>> o.o.b.vm.compiler.IfMinMax.testSingleInt | avgt | 40 | 114.734 | 114.402 | 114.887 | 114.384 | 114.4 | 110.631 | 112.162 | 110.915 | 0.333 | ns/op | 1.003
>> o.o.b.vm.compiler.IfMinMax.testSingleLong | avgt | 40 | 121.53 | 121.711 | 120.91 | 121.665 | 121.309 | 120.57 | 118.639 | 119.373 | 0.451 | ns/op | 1.002
>> o.o.b.vm.compiler.IfMinMax.testVectorInt | avgt | 40 | 60130.165 | 60062.303 | 61839.776 | 61895.194 | 15887.398 | 15924.502 | 15874.835 | 15667.936 | 101.94 | ns/op | 3.785
>> o.o.b.vm.c...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minors

Updated change LGTM. Thanks.

test/hotspot/jtreg/compiler/lib/ir_framework/TestFramework.java line 149:

> 147:                     "UseZbb",
> 148:                     "UseZfh",
> 149:                     "UseZicond",

Is this used anywhere?

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24490#pullrequestreview-2763252248
PR Review Comment: https://git.openjdk.org/jdk/pull/24490#discussion_r2041488979

From duke at openjdk.org  Mon Apr 14 12:53:10 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 14 Apr 2025 12:53:10 GMT
Subject: RFR: 8354513: Bug in j.u.l.Handler deadlock test allows null pointer
 during race condition
Message-ID: 

Add null pointer guard in test formatter (since it can be called with a log record without parameters).

-------------

Commit messages:
 - Adding null check for test formatter.

Changes: https://git.openjdk.org/jdk/pull/24619/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24619&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354513
  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24619.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24619/head:pull/24619

PR: https://git.openjdk.org/jdk/pull/24619

From dfuchs at openjdk.org  Mon Apr 14 12:53:13 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 14 Apr 2025 12:53:13 GMT
Subject: RFR: 8354513: Bug in j.u.l.Handler deadlock test allows null
 pointer during race condition
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Apr 2025 10:56:45 GMT, David Beaumont  wrote:

> Add null pointer guard in test formatter (since it can be called with a log record without parameters).

Trivial fix. Looks like the right thing to do.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24619#pullrequestreview-2764029327

From duke at openjdk.org  Mon Apr 14 12:53:16 2025
From: duke at openjdk.org (duke)
Date: Mon, 14 Apr 2025 12:53:16 GMT
Subject: RFR: 8354513: Bug in j.u.l.Handler deadlock test allows null
 pointer during race condition
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Apr 2025 10:56:45 GMT, David Beaumont  wrote:

> Add null pointer guard in test formatter (since it can be called with a log record without parameters).

@david-beaumont 
Your change (at version 67bea85bb13c3a7c46d28a458230a2a8e51e7f4d) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24619#issuecomment-2801419045

From ihse at openjdk.org  Mon Apr 14 12:53:35 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 14 Apr 2025 12:53:35 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: 
References: 
Message-ID: 

> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
> 
> The fix is basically simple, and includes the following steps:
> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).

Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:

 - Also document UTF-8 requirements (solves JDK-8338973)
 - Let configure only accept utf-8 locales
 - Address review comments from Kim

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24574/files
  - new: https://git.openjdk.org/jdk/pull/24574/files/38004164..452f42dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24574&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24574&range=01-02

  Stats: 47 lines in 7 files changed: 27 ins; 2 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/24574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24574/head:pull/24574

PR: https://git.openjdk.org/jdk/pull/24574

From shade at openjdk.org  Mon Apr 14 12:54:10 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 14 Apr 2025 12:54:10 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 26 Mar 2025 17:31:47 GMT, Aleksey Shipilev  wrote:

>> When jspawnhelper fails for whatever reason, but more prominently due to [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the errors into stdout, but not to the relevant `IOException`. So, if the application is configured to only capture the exception logs (e.g. through `java.util.logging`), we will miss any output from `jspawnhelper`, and user would be left without a clue what have happened. We have seen customers spending weeks trying to figure out what went wrong.
>> 
>> It would be good to provide useful `IOException` when `jspawnhelper` fails. We already have a precedent with vmError [printing helpful suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) when VM fails, we can do a similar thing here. 
>> 
>> I am very open to bike-shedding about the actual message :)
>> 
>> Additional testing:
>>  - [x] Ad-hoc experiments with breaking jspawnhelper
>>  - [x] macos-aarch64-server-fastdebug, `java/lang/Process java/lang/ProcessBuilder`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pull message into a field

@AlanBateman, maybe?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24149#issuecomment-2800915190

From kbarrett at openjdk.org  Mon Apr 14 12:53:53 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 14 Apr 2025 12:53:53 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 13 Apr 2025 23:14:41 GMT, Magnus Ihse Bursie  wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also tell javadoc that we have utf-8 now

A couple of drive-by comments.  Don't count me as a Reviewer for this.

make/autoconf/flags-cflags.m4 line 577:

> 575:   elif test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
> 576:     # The -utf-8 option sets source and execution character sets to UTF-8 to enable correct
> 577:     # compilation of all source files regardless of the active code page on Windows.

Seems like this comment should be updated and moved near the new code block for setting up `CHARSET_CFLAGS`.

make/common/JavaCompilation.gmk line 83:

> 81: # The sed expression does this:
> 82: # 1. Add a backslash before any :, = or ! that do not have a backslash already.
> 83: # 3. Delete all lines starting with #.

There is no item 2 anymore, so following bullets are misnumbered.

-------------

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24574#pullrequestreview-2762999364
PR Review Comment: https://git.openjdk.org/jdk/pull/24574#discussion_r2041326051
PR Review Comment: https://git.openjdk.org/jdk/pull/24574#discussion_r2041328098

From ihse at openjdk.org  Mon Apr 14 12:53:56 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 14 Apr 2025 12:53:56 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 13 Apr 2025 23:14:41 GMT, Magnus Ihse Bursie  wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also tell javadoc that we have utf-8 now

Inspired by [Phil's comment in JDK-8353948](https://bugs.openjdk.org/browse/JDK-8353948?focusedId=14769043&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14769043), I also modified configure to only allow utf-8 environments, but to also allow `en_US.UTF-8` as a valid locale. 

This also resolves [JDK-8333247](https://bugs.openjdk.org/browse/JDK-8333247) in a better way.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2800741990

From jengebr at amazon.com  Mon Apr 14 12:59:04 2025
From: jengebr at amazon.com (Engebretson, John)
Date: Mon, 14 Apr 2025 12:59:04 +0000
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: <4c4aac5737d844a4959885c65f17efee@amazon.com>
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 
 <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 
 
 <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
 
 <3f1c69a7ac5946809d2af850d7d59db9@amazon.com>
 
 
 
 <4741eceb3beb40c2bc82613c67836d66@amazon.com>
 
 
 
 <4c4aac5737d844a4959885c65f17efee@amazon.com>
Message-ID: <0249c80513c74209b34b63cce0f7a2c8@amazon.com>

I thought about this over the weekend, and I think the byte[] variant and the Object[] variant target separate problems: byte[] targets I/O patterns and Object[]
targets Collections.

So my current mental model is:

public class java.io.VariableLengthByteArray {
  // whatever views we want to support
  public ByteArrayOutputStream asOutputStream();
  public InputStream asInputStream();
  public SeekableByteChannel asByteChannel;

  // provides long-indexed methods
  public byte get(long index);
  public long get(long index, byte[] buf);
  public byte set(long index, byte b); // return old value
  public long size(); // note the long

  // optional: inserts/removes by long index

  // add to tail
  public void add(byte b);
  public void add(byte[] b, int off, int len);
  public void add(VariableLengthByteArray other);
  public void add(ByteBuffer buf);

  // size-limited methods
  public int sizeAsInt(); // requires int range
  public byte[] toArray(); // requires int range
  public String toString(); // requires int range

  // miscellaneous
  public void clear();
}

public class java.util.HugeCollections {
  // views are capable and efficient with size > Integer.MAX_VALUE
  public static  List getList(); // this structure
  public static  Set getSet(); // segmented hash table
  public static  Map getMap(); // segmented hash table

  // how do we retrieve the long size?
}

Unfortunately, I don't see a way to avoid two public types while retaining the capabilities.
Archie, thank you for all of the questions/suggestions last week, they really sparked some ideas.
  John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From tpushkin at openjdk.org  Mon Apr 14 14:00:40 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 14 Apr 2025 14:00:40 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v7]
In-Reply-To: 
References: 
Message-ID: 

> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app.
> 
> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible.

Timofei Pushkin has updated the pull request incrementally with two additional commits since the last revision:

 - Fix indentation
 - Extend ClassFromClasspath test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24223/files
  - new: https://git.openjdk.org/jdk/pull/24223/files/903f0f97..d2e51dac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=05-06

  Stats: 75 lines in 3 files changed: 62 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/24223.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223

PR: https://git.openjdk.org/jdk/pull/24223

From tpushkin at openjdk.org  Mon Apr 14 14:04:33 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 14 Apr 2025 14:04:33 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v8]
In-Reply-To: 
References: 
Message-ID: 

> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app.
> 
> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible.

Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24223/files
  - new: https://git.openjdk.org/jdk/pull/24223/files/d2e51dac..fca3c919

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=06-07

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24223.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223

PR: https://git.openjdk.org/jdk/pull/24223

From rriggs at openjdk.org  Mon Apr 14 14:24:44 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 14 Apr 2025 14:24:44 GMT
Subject: RFR: 8354053: Remove unused JavaIOFilePermissionAccess
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Apr 2025 21:26:08 GMT, Roger Riggs  wrote:

> The JavaIOFilePermissionAccess interface is removed from SharedSecrets and its implementation (FilePermCompat.java) used by the test is moved to java.io FilePermission where cross package access is not needed. 
> The test FilePermissionCollectionMerge is updated to access the internal implementation in FilePermission. 
> Modernized the initialization from the system property `jdk.io.permissionsUseCanonicalPath`. 
> The remaining support will be removed when FilePermission is removed.

I considered dropping the property support, but it seemed harmless to leave it until FilePermission is removed and avoids thrash in an unused implementation and documentation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24603#issuecomment-2801882511

From dfuchs at openjdk.org  Mon Apr 14 14:24:51 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 14 Apr 2025 14:24:51 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 21:26:21 GMT, Michael McMahon  wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to minimise code changes

src/java.base/share/classes/java/net/NetworkInterface.java line 329:

> 327:         } else {
> 328:             throw new IllegalArgumentException(
> 329:                 formatMsg("invalid address type%s", filterNetInfo(addr.toString()).prefixWith(": ")));

OK - I see that `addr` cannot be null if we reach here.

src/java.base/share/classes/java/net/Proxy.java line 101:

> 99:             throw new IllegalArgumentException(
> 100:                 formatMsg("type " + type + " is not compatible with address %s",
> 101:                           filterNetInfo(sa.toString())

You will get NullPointerException instead of IllegalArgumentException if `sa` is `null`. I suggest using `String.valueOf(sa)` rather than `sa.toString()` to preserve the pre-existing behaviour.

src/java.base/share/classes/java/net/Proxy.java line 102:

> 100:                 formatMsg("type " + type + " is not compatible with address %s",
> 101:                           filterNetInfo(sa.toString())
> 102:                                .replaceWith("type " + sa.getClass().toString())));

You will have to guard against sa == null here

src/java.base/share/classes/jdk/internal/util/Exceptions.java line 253:

> 251: 
> 252:         int i = 0;
> 253:         boolean enhanced = true;

`enhanced` doesn't seem to be used here. Is this some leftover?

src/java.base/share/classes/sun/net/www/protocol/jar/Handler.java line 203:

> 201:                 throw new NullPointerException(
> 202:                     formatMsg("malformed context url%s : no !/",
> 203:                               filterJarName(url.toString()).prefixWith(": ")));

It's not clear whether `url` could be `null` here, so to sidestep the question maybe use `String::valueOf` rather than `Object::toString`.

src/java.base/share/classes/sun/net/www/protocol/jar/Handler.java line 212:

> 210:                 throw new NullPointerException(
> 211:                     formatMsg("malformed context url%s",
> 212:                               filterJarName(url.toString()).prefixWith(": ")));

Same remark here

test/jdk/java/net/URI/Test.java line 29:

> 27:  *      7171415 6339649 6933879 8037396 8272072 8051627 8297687
> 28:  * @author Mark Reinhold
> 29:  * @run main/othervm -Djdk.includeInExceptions=hostInfo Test

This change does not look like it's needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042182598
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042187411
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042190019
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042199577
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042214144
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042215273
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042244694

From pminborg at openjdk.org  Mon Apr 14 15:00:00 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 14 Apr 2025 15:00:00 GMT
Subject: RFR: 8354300: Fields in String are not trusted
Message-ID: 

This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and `j.l.String.hashIsZero`. This means the VM can trust these fields to never change which enables constant folding optimizations.

This PR is tested in tier1, tier2, and tier3 which all pass.

-------------

Commit messages:
 - Update copyright year
 - Annotate fields with @Stable

Changes: https://git.openjdk.org/jdk/pull/24625/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24625&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354300
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24625/head:pull/24625

PR: https://git.openjdk.org/jdk/pull/24625

From tpushkin at openjdk.org  Mon Apr 14 15:06:41 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 14 Apr 2025 15:06:41 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v5]
In-Reply-To: 
References: 
 <9nX8O13jWi7qORu4uO-ppDmlph2W2lH1VVIKFP3-Gt8=.46545db1-b218-497d-b4ef-546410b09b9b@github.com>
 
 
 
 
 
Message-ID: 

On Thu, 10 Apr 2025 16:01:20 GMT, Ioi Lam  wrote:

>> Currently we have some restrictions if`-Djava.system.class.loader=` is specified
>> 
>> - we disable full module graph archiving: https://github.com/openjdk/jdk/blob/0e223f1456c14efdb423595bee3444d5e26db7c6/src/hotspot/share/cds/cdsConfig.cpp#L286
>> - we disable loading archived classes for platform and system loaders: https://github.com/openjdk/jdk/blob/0e223f1456c14efdb423595bee3444d5e26db7c6/src/hotspot/share/cds/filemap.cpp#L1874-L1886
>> 
>> I think we should extend this limitation further (in a separate issue)
>> 
>> - At dump time, dump only boot classes (no platform, system or unregistered)
>> - At run time, load only boot classes (no platform, system or unregistered)
>> 
>> I filed [JDK-8354315](https://bugs.openjdk.org/browse/JDK-8354315)
>
> In the current JDK (with or without this patch), in your scenario, I think the name "S" will be printed twice with two different IDs. If a Child class named "C" is loaded by a custom loader, it will refer to one of the IDs. Depending on the order of loading, it might refer to the first or the second ID.
> 
> During dump time, we will try to load this class twice, but both attempts will result in the same class (defined by the user-defined system class loader). When resolving the unregistered class, using either ID will give you the correct super class ...
> 
> Anyway, this seems too fragile. I think we should fix [JDK-8354315](https://bugs.openjdk.org/browse/JDK-8354315) before integrating this patch. Or, maybe we can include the fixes of that bug in this PR as well (and then close that bug as a duplicate of this one). What do you think?

In my scenario I actually meant that  is in the class list while  is not but it doesn't matter much, the incorrect one will be loaded any way.

Since the new implementation will behave the same as the existing one in this aspect I think it is OK to fix JDK-8354315 separately.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2042346769

From vaivanov at openjdk.org  Mon Apr 14 15:22:21 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 14 Apr 2025 15:22:21 GMT
Subject: RFR: 8346230: [perf] scalability issue for the
 specjvm2008::xml.transform workload [v6]
In-Reply-To: 
References: 
Message-ID: 

> The HashMap for caching was deleted. Now it use only ThreadLocal variable without synchronization.
> According to the specjvm2008::xml.transform workload the performance for low threads counts was not affected and improved for high threads counts. 
> For the 2 socket server based on Xeon 6780E reported scores are (average for 3 runs):
> 2x6780E | 1C | 32C | 64C | 96C | 128C | 160C | 192C | 224C | 256C | 288C
> orig        | 138.9567 | 4127.567 | 8203.907 | 12252.07 | 15496.65 | 16222.91 | 15846.48 | 14758.43 | 14612.34 | 13969.25
> patched | 139.7067 | 4118.763 | 8352.657 | 12491.14 | 16085.63 | 18101.67 | 21001.52 | 23847.33 | 26481.25 | 28273.93

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  8346230: [perf] scalability issue for the specjvm2008::xml.transform workload

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23185/files
  - new: https://git.openjdk.org/jdk/pull/23185/files/cf4c59f4..756706d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23185&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23185&range=04-05

  Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23185.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23185/head:pull/23185

PR: https://git.openjdk.org/jdk/pull/23185

From vaivanov at openjdk.org  Mon Apr 14 15:22:22 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 14 Apr 2025 15:22:22 GMT
Subject: RFR: 8346230: [perf] scalability issue for the
 specjvm2008::xml.transform workload [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 11 Apr 2025 10:06:06 GMT, Jatin Bhateja  wrote:

>> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8346230: [perf] scalability issue for the specjvm2008::xml.transform workload
>
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java line 112:
> 
>> 110:         reader = threadHasReader ? rw.reader : null;
>> 111:         String factory = System.getProperty(property);
>> 112:         if (threadHasReader &&
> 
> Please modify the comments to reflect your new behaviour.

Comments were updated. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23185#discussion_r2042376228

From vaivanov at openjdk.org  Mon Apr 14 15:26:52 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 14 Apr 2025 15:26:52 GMT
Subject: RFR: 8346230: [perf] scalability issue for the
 specjvm2008::xml.transform workload [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 11 Apr 2025 10:13:41 GMT, Jatin Bhateja  wrote:

>> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8346230: [perf] scalability issue for the specjvm2008::xml.transform workload
>
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java line 148:
> 
>> 146:         // for this thread, remove it.
>> 147:         ReaderWrapper rw = m_readers.get();
>> 148:         if (rw != null && rw.reader == reader && reader != null) {
> 
> Suggestion:
> 
>         if (rw != null && rw.reader == reader) {

For the first glance, some parameters check should be OK for public method. Seems, the rw.reader should not be 'null' now if 'rw' was initialized but it is small check not in the 'hot' path. It may be OK to have it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23185#discussion_r2042387492

From tpushkin at openjdk.org  Mon Apr 14 15:28:11 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Mon, 14 Apr 2025 15:28:11 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v6]
In-Reply-To: 
References: 
 
 
Message-ID: <-r-008S-HtyyMBystnDKZZUaiCGdbUHSx7v87MeWatA=.02df1f9f-a85e-4136-a1a7-672782415527@github.com>

On Thu, 10 Apr 2025 16:04:59 GMT, Ioi Lam  wrote:

>> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove findClass, extend explanation comments
>
> test/hotspot/jtreg/runtime/cds/appcds/customLoader/ClassFromClasspath.java line 53:
> 
>> 51:         out.shouldContain("unreg CustomLoadee");
>> 52:     }
>> 53: }
> 
> For completeness, I think we should have a more complicated scenario:
> 
> - load CustomLoadee in both the app loader and a custom loader
> - load CustomLoadeeChild in the custom loader. Its super class should be the one defined in the custom loader
> 
> At run time, verify that CustomLoadeeChild is archived and its super class is defined in the custom loader

This case will work, I've added the test, however I found another case which won't be handled correctly, neither before nor after this change.

This is the case you've suggested, it works fine both before and after the change.

java/lang/Object id: 0
CustomLoadee3 id: 1
CustomLoadee3 id: 2 super: 0 source: a.jar
CustomLoadee3Child id: 3 super: 2 source: a.jar


However the below one doesn't work neither before nor after this change. At dump time, 2 is loaded instead of 1 as the super of 3 because 2, 3 are loaded by the same class loader and 1, 2 have the same name. It is possible to get such class list if 2 is loaded by a non-delegating unregistered loader while 3 is loaded by a different delegating one. 

# Difference with the previous: super of the last class
java/lang/Object id: 0
CustomLoadee3 id: 1
CustomLoadee3 id: 2 super: 0 source: a.jar
CustomLoadee3Child id: 3 super: 1 source: a.jar


And the following case is working without this change but will not work with it. It is working now because there will be two different unregistered loaders for classes 2 and 3 (because they have the same source), however with this change there will be one and it will re-use 2 already loaded by it when loading 3.

# Difference with the previous: source of the last class
java/lang/Object id: 0
CustomLoadee3 id: 1
CustomLoadee3 id: 2 super: 0 source: a.jar
CustomLoadee3Child id: 3 super: 1 source: b.jar

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2042386067

From pminborg at openjdk.org  Mon Apr 14 15:31:12 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 14 Apr 2025 15:31:12 GMT
Subject: RFR: 8348556: Inlining fails earlier for
 MemorySegment::reinterpret [v7]
In-Reply-To: 
References: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
 
Message-ID: 

On Tue, 8 Apr 2025 12:24:41 GMT, Per Minborg  wrote:

>> This PR proposes to add some `@ForceInline` annotations in the `Module` class in order to assist inlining of FFM var/method handles.
>> 
>> There are also some changes in other classes which, if implemented, can take us three additional levels of inlining. I drew a line there. There is a tradeoff with adding `@ForceInline` and just trying to get as deep as possible for a specific use case is probably not the best idea. 
>> 
>> Updating the `j.l.Object` constructor is crucial for the higher depths.
>> 
>> Tested and passed tier1-3
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reintroduce Object changes

@iwanowww : Do you have any comments on this PR? Should we just close it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23460#issuecomment-2802091492

From pminborg at openjdk.org  Mon Apr 14 15:33:52 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 14 Apr 2025 15:33:52 GMT
Subject: RFR: 8350075: Performance difference between SegmentAllocator
 methods [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 06:00:48 GMT, Per Minborg  wrote:

>> This PR proposes to add `@ForceInline` to the `default` methods in `SegmentAllocator` that do not already have it.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Add benchmark
>  - Merge branch 'master' into ms-add-missing-force-inline
>  - Add @ForceInline to default methods

Looking at it from another perspective: Why should some default methods be FI and not others? What are the rationales for FI:ing the ones that are and not the ones that are not? With this PR, we would at least be consistent.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23628#issuecomment-2802102823

From jpai at openjdk.org  Mon Apr 14 15:49:45 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 14 Apr 2025 15:49:45 GMT
Subject: RFR: 8354300: Fields in String are not trusted
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Apr 2025 14:47:59 GMT, Per Minborg  wrote:

> This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and `j.l.String.hashIsZero`. This means the VM can trust these fields to never change which enables constant folding optimizations.
> 
> This PR is tested in tier1, tier2, and tier3 which all pass.

Hello Per, I'm not too familiar with runtime compiler optimizations. So consider this as a basic question. 

> This means the VM can trust these fields to never change which enables constant folding optimizations.

If I'm not wrong, then it is the `hash` field value that we want to be considered as a constant (once computed) so that calls to `String.hashCode()` would get replaced with the constant computed value.

Looking at the current implementation of `String.hashCode()`:


public int hashCode() {
        // The hash or hashIsZero fields are subject to a benign data race,
        // making it crucial to ensure that any observable result of the
        // calculation in this method stays correct under any possible read of
        // these fields. Necessary restrictions to allow this to be correct
        // without explicit memory fences or similar concurrency primitives is
        // that we can ever only write to one of these two fields for a given
        // String instance, and that the computation is idempotent and derived
        // from immutable state
        int h = hash;
        if (h == 0 && !hashIsZero) {
            h = isLatin1() ? StringLatin1.hashCode(value)
                           : StringUTF16.hashCode(value);
            if (h == 0) {
                hashIsZero = true;
            } else {
                hash = h;
            }
        }
        return h;
    }


If I'm reading that correctly, and keeping aside concurrent calls from this discussion, then only one of `hash` or the `hashIsZero` fields will have its value changed to a non-default value. i.e. if `hashCode()` implementation computes a non-zero value then the `hash` field will be assigned a (non-default) value and if that method computes a hash of 0, then `hashIsZero` will get assigned a (non-default) value. It then means that the other field will never move out of its initial value and thus will never be considered "stable".

Am I right? If yes, then would the runtime (hotspot) compiler still replace the call to `String.hashCode()` with a constant value?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24625#issuecomment-2802149233

From duke at openjdk.org  Mon Apr 14 16:02:06 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 14 Apr 2025 16:02:06 GMT
Subject: Integrated: 8354513: Bug in j.u.l.Handler deadlock test allows null
 pointer during race condition
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Apr 2025 10:56:45 GMT, David Beaumont  wrote:

> Add null pointer guard in test formatter (since it can be called with a log record without parameters).

This pull request has now been integrated.

Changeset: 313c34ae
Author:    David Beaumont 
Committer: Daniel Fuchs 
URL:       https://git.openjdk.org/jdk/commit/313c34ae56085f90f4188b0639d6b6595efc2f66
Stats:     6 lines in 1 file changed: 4 ins; 0 del; 2 mod

8354513: Bug in j.u.l.Handler deadlock test allows null pointer during race condition

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/24619

From naoto at openjdk.org  Mon Apr 14 16:12:47 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 14 Apr 2025 16:12:47 GMT
Subject: RFR: 8343157: Examine large files for character encoding/decoding
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Apr 2025 17:02:13 GMT, Naoto Sato  wrote:

> Removing old charset test cases that verify new charset implementations (as of JDK7). Removed tests/files are actual charset implementations used in pre-JDK7, which have been used for comparing the results. Since those "new" implementations have been used since then, I believe it is OK to retire those old test cases.

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24597#issuecomment-2802205991

From naoto at openjdk.org  Mon Apr 14 16:12:47 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 14 Apr 2025 16:12:47 GMT
Subject: Integrated: 8343157: Examine large files for character
 encoding/decoding
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Apr 2025 17:02:13 GMT, Naoto Sato  wrote:

> Removing old charset test cases that verify new charset implementations (as of JDK7). Removed tests/files are actual charset implementations used in pre-JDK7, which have been used for comparing the results. Since those "new" implementations have been used since then, I believe it is OK to retire those old test cases.

This pull request has now been integrated.

Changeset: d748bb5c
Author:    Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/d748bb5cbb983fb07ae28e3a1c194058b73ef652
Stats:     164679 lines in 55 files changed: 0 ins; 164677 del; 2 mod

8343157: Examine large files for character encoding/decoding

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/24597

From rriggs at openjdk.org  Mon Apr 14 16:14:03 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 14 Apr 2025 16:14:03 GMT
Subject: RFR: 8354053: Remove unused JavaIOFilePermissionAccess [v2]
In-Reply-To: 
References: 
Message-ID: 

> The JavaIOFilePermissionAccess interface is removed from SharedSecrets and its implementation (FilePermCompat.java) used by the test is moved to java.io FilePermission where cross package access is not needed. 
> The test FilePermissionCollectionMerge is updated to access the internal implementation in FilePermission. 
> Modernized the initialization from the system property `jdk.io.permissionsUseCanonicalPath`. 
> The remaining support will be removed when FilePermission is removed.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Simplify as suggested in review comments
  Convert static methods to instance methods and invoke on the existing FilePermission.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24603/files
  - new: https://git.openjdk.org/jdk/pull/24603/files/721fba81..56680c47

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24603&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24603&range=00-01

  Stats: 27 lines in 2 files changed: 1 ins; 2 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/24603.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24603/head:pull/24603

PR: https://git.openjdk.org/jdk/pull/24603

From rriggs at openjdk.org  Mon Apr 14 16:17:48 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 14 Apr 2025 16:17:48 GMT
Subject: RFR: 8354053: Remove unused JavaIOFilePermissionAccess [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 14 Apr 2025 16:14:03 GMT, Roger Riggs  wrote:

>> The JavaIOFilePermissionAccess interface is removed from SharedSecrets and its implementation (FilePermCompat.java) used by the test is moved to java.io FilePermission where cross package access is not needed. 
>> The test FilePermissionCollectionMerge is updated to access the internal implementation in FilePermission. 
>> Modernized the initialization from the system property `jdk.io.permissionsUseCanonicalPath`. 
>> The remaining support will be removed when FilePermission is removed.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify as suggested in review comments
>   Convert static methods to instance methods and invoke on the existing FilePermission.

Note: FilePermissionCollectionMerge has never worked when `jdk.io.permissionsUseCanonicalPath=true`.
The creation of the alternate FilePermission gets an NPE because the internal npath is null.
And still does not; it is not worth fixing since FilePermission is to be removed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24603#issuecomment-2802221485

From joehw at openjdk.org  Mon Apr 14 16:47:42 2025
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 14 Apr 2025 16:47:42 GMT
Subject: RFR: 8346230: [perf] scalability issue for the
 specjvm2008::xml.transform workload [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 14 Apr 2025 15:22:21 GMT, Vladimir Ivanov  wrote:

>> The HashMap for caching was deleted. Now it use only ThreadLocal variable without synchronization.
>> According to the specjvm2008::xml.transform workload the performance for low threads counts was not affected and improved for high threads counts. 
>> For the 2 socket server based on Xeon 6780E reported scores are (average for 3 runs):
>> 2x6780E | 1C | 32C | 64C | 96C | 128C | 160C | 192C | 224C | 256C | 288C
>> orig        | 138.9567 | 4127.567 | 8203.907 | 12252.07 | 15496.65 | 16222.91 | 15846.48 | 14758.43 | 14612.34 | 13969.25
>> patched | 139.7067 | 4118.763 | 8352.657 | 12491.14 | 16085.63 | 18101.67 | 21001.52 | 23847.33 | 26481.25 | 28273.93
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8346230: [perf] scalability issue for the specjvm2008::xml.transform workload

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23185#pullrequestreview-2764961182

From vaivanov at openjdk.org  Mon Apr 14 16:53:53 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 14 Apr 2025 16:53:53 GMT
Subject: RFR: 8346230: [perf] scalability issue for the
 specjvm2008::xml.transform workload [v6]
In-Reply-To: 
References: 
 
Message-ID: <9whpRCJJN9BUXXNmvZ0faXU1bOJIhtSPnI4mjv8iv9Y=.ff387eaf-d981-4673-b163-329c3ca1be32@github.com>

On Mon, 14 Apr 2025 15:22:21 GMT, Vladimir Ivanov  wrote:

>> The HashMap for caching was deleted. Now it use only ThreadLocal variable without synchronization.
>> According to the specjvm2008::xml.transform workload the performance for low threads counts was not affected and improved for high threads counts. 
>> For the 2 socket server based on Xeon 6780E reported scores are (average for 3 runs):
>> 2x6780E | 1C | 32C | 64C | 96C | 128C | 160C | 192C | 224C | 256C | 288C
>> orig        | 138.9567 | 4127.567 | 8203.907 | 12252.07 | 15496.65 | 16222.91 | 15846.48 | 14758.43 | 14612.34 | 13969.25
>> patched | 139.7067 | 4118.763 | 8352.657 | 12491.14 | 16085.63 | 18101.67 | 21001.52 | 23847.33 | 26481.25 | 28273.93
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8346230: [perf] scalability issue for the specjvm2008::xml.transform workload

Thanks everyone for your review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23185#issuecomment-2802306618

From duke at openjdk.org  Mon Apr 14 16:53:53 2025
From: duke at openjdk.org (duke)
Date: Mon, 14 Apr 2025 16:53:53 GMT
Subject: RFR: 8346230: [perf] scalability issue for the
 specjvm2008::xml.transform workload [v6]
In-Reply-To: 
References: 
 
Message-ID: <8TaQFHmTkQTQ3MfA5zd9i9-REu_5M70e7GoEMJ2xpno=.f105ffb5-6880-4895-aa45-0ba0ac4c9602@github.com>

On Mon, 14 Apr 2025 15:22:21 GMT, Vladimir Ivanov  wrote:

>> The HashMap for caching was deleted. Now it use only ThreadLocal variable without synchronization.
>> According to the specjvm2008::xml.transform workload the performance for low threads counts was not affected and improved for high threads counts. 
>> For the 2 socket server based on Xeon 6780E reported scores are (average for 3 runs):
>> 2x6780E | 1C | 32C | 64C | 96C | 128C | 160C | 192C | 224C | 256C | 288C
>> orig        | 138.9567 | 4127.567 | 8203.907 | 12252.07 | 15496.65 | 16222.91 | 15846.48 | 14758.43 | 14612.34 | 13969.25
>> patched | 139.7067 | 4118.763 | 8352.657 | 12491.14 | 16085.63 | 18101.67 | 21001.52 | 23847.33 | 26481.25 | 28273.93
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8346230: [perf] scalability issue for the specjvm2008::xml.transform workload

@IvaVladimir 
Your change (at version 756706d1bb3b3b57e532b6fee57bbe3206f70dca) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23185#issuecomment-2802309013

From jbhateja at openjdk.org  Mon Apr 14 16:58:58 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 14 Apr 2025 16:58:58 GMT
Subject: RFR: 8346230: [perf] scalability issue for the
 specjvm2008::xml.transform workload [v6]
In-Reply-To: 
References: 
 
Message-ID: <1wNFm_vNLgTDACtU5xKzuy2wMLj8H01_3p1pmD30qwE=.aa986c9e-2689-4d08-ae52-b7956e64cfc3@github.com>

On Mon, 14 Apr 2025 15:22:21 GMT, Vladimir Ivanov  wrote:

>> The HashMap for caching was deleted. Now it use only ThreadLocal variable without synchronization.
>> According to the specjvm2008::xml.transform workload the performance for low threads counts was not affected and improved for high threads counts. 
>> For the 2 socket server based on Xeon 6780E reported scores are (average for 3 runs):
>> 2x6780E | 1C | 32C | 64C | 96C | 128C | 160C | 192C | 224C | 256C | 288C
>> orig        | 138.9567 | 4127.567 | 8203.907 | 12252.07 | 15496.65 | 16222.91 | 15846.48 | 14758.43 | 14612.34 | 13969.25
>> patched | 139.7067 | 4118.763 | 8352.657 | 12491.14 | 16085.63 | 18101.67 | 21001.52 | 23847.33 | 26481.25 | 28273.93
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8346230: [perf] scalability issue for the specjvm2008::xml.transform workload

Marked as reviewed by jbhateja (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23185#pullrequestreview-2764985284

From jbhateja at openjdk.org  Mon Apr 14 16:58:59 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 14 Apr 2025 16:58:59 GMT
Subject: RFR: 8346230: [perf] scalability issue for the
 specjvm2008::xml.transform workload [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 14 Apr 2025 15:23:45 GMT, Vladimir Ivanov  wrote:

>> src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java line 148:
>> 
>>> 146:         // for this thread, remove it.
>>> 147:         ReaderWrapper rw = m_readers.get();
>>> 148:         if (rw != null && rw.reader == reader && reader != null) {
>> 
>> Suggestion:
>> 
>>         if (rw != null && rw.reader == reader) {
>
> For the first glance, some parameters check should be OK for public method. Seems, the rw.reader should not be 'null' now if 'rw' was initialized but it is small check not in the 'hot' path. It may be OK to have it.

Yes, it was nit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23185#discussion_r2042534343

From vaivanov at openjdk.org  Mon Apr 14 16:59:00 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 14 Apr 2025 16:59:00 GMT
Subject: Integrated: 8346230: [perf] scalability issue for the
 specjvm2008::xml.transform workload
In-Reply-To: 
References: 
Message-ID: <9War6M28sOz88qsmPugUeDCGfrFvezGpIDO_F2hFWI4=.7b5be173-cbbb-4330-8c69-414655b384fc@github.com>

On Fri, 17 Jan 2025 23:08:20 GMT, Vladimir Ivanov  wrote:

> The HashMap for caching was deleted. Now it use only ThreadLocal variable without synchronization.
> According to the specjvm2008::xml.transform workload the performance for low threads counts was not affected and improved for high threads counts. 
> For the 2 socket server based on Xeon 6780E reported scores are (average for 3 runs):
> 2x6780E | 1C | 32C | 64C | 96C | 128C | 160C | 192C | 224C | 256C | 288C
> orig        | 138.9567 | 4127.567 | 8203.907 | 12252.07 | 15496.65 | 16222.91 | 15846.48 | 14758.43 | 14612.34 | 13969.25
> patched | 139.7067 | 4118.763 | 8352.657 | 12491.14 | 16085.63 | 18101.67 | 21001.52 | 23847.33 | 26481.25 | 28273.93

This pull request has now been integrated.

Changeset: d6848670
Author:    Vladimir Ivanov 
Committer: Jatin Bhateja 
URL:       https://git.openjdk.org/jdk/commit/d684867066edb886bc444c864ef9db3eff318c34
Stats:     25 lines in 1 file changed: 1 ins; 15 del; 9 mod

8346230: [perf] scalability issue for the specjvm2008::xml.transform workload

Reviewed-by: joehw, jbhateja

-------------

PR: https://git.openjdk.org/jdk/pull/23185

From pminborg at openjdk.org  Mon Apr 14 17:13:46 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 14 Apr 2025 17:13:46 GMT
Subject: RFR: 8354300: Fields in String are not trusted
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Apr 2025 14:47:59 GMT, Per Minborg  wrote:

> This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and `j.l.String.hashIsZero`. This means the VM can trust these fields to never change which enables constant folding optimizations.
> 
> This PR is tested in tier1, tier2, tier3, and tier4 which all pass.

With the proposed changes, the JVM is able to constant-fold the hash value. See:

https://github.com/openjdk/jdk/pull/23972#issuecomment-2793199126

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24625#issuecomment-2802361777

From kbarrett at openjdk.org  Mon Apr 14 17:36:47 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 14 Apr 2025 17:36:47 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 14 Apr 2025 12:53:35 GMT, Magnus Ihse Bursie  wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim

My comments have been addressed.  Let's see if this is sufficient to clear my
"request changes" state.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24574#pullrequestreview-2765099003

From shade at openjdk.org  Mon Apr 14 17:39:46 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 14 Apr 2025 17:39:46 GMT
Subject: RFR: 8354300: Fields in String are not trusted
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Apr 2025 14:47:59 GMT, Per Minborg  wrote:

> This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and `j.l.String.hashIsZero`. This means the VM can trust these fields to never change which enables constant folding optimizations.
> 
> This PR is tested in tier1, tier2, tier3, and tier4 which all pass.

Looks good to me.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24625#pullrequestreview-2765106046

From shade at openjdk.org  Mon Apr 14 17:39:46 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 14 Apr 2025 17:39:46 GMT
Subject: RFR: 8354300: Fields in String are not trusted
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 14 Apr 2025 15:46:54 GMT, Jaikiran Pai  wrote:

>  It then means that the other field will never move out of its initial value and thus will never be considered "stable".

For all non-zero hashcodes, it matters that `hash` would be constant-foldable, which means `if (h == 0 && !hashIsZero)` would be optimized to `if (false && !hashIsZero)` -> `if (false)` -> poof. So it would not matter if `hashIsZero` is actually foldable. 

Same goes the other way around for the hashcode that _is_ zero: now `!hashIsZero` would be folded to `false` -- with a wrinkle that `int h = hash;` read would likely still be there... You can massage the code a bit to return `0` if `hashIsZero`, but I don't think it is worth it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24625#issuecomment-2802411963

From liach at openjdk.org  Mon Apr 14 18:03:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Apr 2025 18:03:49 GMT
Subject: RFR: 8354300: Fields in String are not trusted
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Apr 2025 14:47:59 GMT, Per Minborg  wrote:

> This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and `j.l.String.hashIsZero`. This means the VM can trust these fields to never change which enables constant folding optimizations.
> 
> This PR is tested in tier1, tier2, tier3, and tier4 which all pass.

This does not fix the lack of constant folding.

The regression for https://github.com/openjdk/jdk/pull/23972#issuecomment-2792664301 appears again if the `Map::get` call uses `""` instead of `"x"` or `"y"`.

-------------

Changes requested by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24625#pullrequestreview-2765156275

From liach at openjdk.org  Mon Apr 14 18:09:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Apr 2025 18:09:47 GMT
Subject: RFR: 8354300: Fields in String are not trusted
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Apr 2025 14:47:59 GMT, Per Minborg  wrote:

> This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and `j.l.String.hashIsZero`. This means the VM can trust these fields to never change which enables constant folding optimizations.
> 
> This PR is tested in tier1, tier2, tier3, and tier4 which all pass.

As recommended by @iwanowww, an approach is to write 2 to `hashIsZero` if we calculated a non-zero hash, so we can constant-fold zero hashes like:



var isZero = hashIsZero;
if (isZero == 1) return 0;
if (isZero == 2) {
    int h = hash;
    if (h != 0) return h;
}
return computeHash(); // and set hash, hashIsZero fields


I tried something like that at https://github.com/liachmodded/jdk/commit/f265710ce7d2d02ee51d6429b5603ecc0590c383, but did not submit because it end up still having a regression compared to baseline in remi's benchmark, with the resulting throughput/average cost between the other constant cases and the non-folding string hash cases.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24625#issuecomment-2802485318

From liach at openjdk.org  Mon Apr 14 18:12:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Apr 2025 18:12:55 GMT
Subject: RFR: 8354300: Fields in String are not trusted
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 14 Apr 2025 15:46:54 GMT, Jaikiran Pai  wrote:

>> This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and `j.l.String.hashIsZero`. This means the VM can trust these fields to never change which enables constant folding optimizations.
>> 
>> This PR is tested in tier1, tier2, tier3, and tier4 which all pass.
>
> Hello Per, I'm not too familiar with runtime compiler optimizations. So consider this as a basic question. 
> 
>> This means the VM can trust these fields to never change which enables constant folding optimizations.
> 
> If I'm not wrong, then it is the `hash` field value that we want to be considered as a constant (once computed) so that calls to `String.hashCode()` would get replaced with the constant computed value.
> 
> Looking at the current implementation of `String.hashCode()`:
> 
> 
> public int hashCode() {
>         // The hash or hashIsZero fields are subject to a benign data race,
>         // making it crucial to ensure that any observable result of the
>         // calculation in this method stays correct under any possible read of
>         // these fields. Necessary restrictions to allow this to be correct
>         // without explicit memory fences or similar concurrency primitives is
>         // that we can ever only write to one of these two fields for a given
>         // String instance, and that the computation is idempotent and derived
>         // from immutable state
>         int h = hash;
>         if (h == 0 && !hashIsZero) {
>             h = isLatin1() ? StringLatin1.hashCode(value)
>                            : StringUTF16.hashCode(value);
>             if (h == 0) {
>                 hashIsZero = true;
>             } else {
>                 hash = h;
>             }
>         }
>         return h;
>     }
> 
> 
> If I'm reading that correctly, and keeping aside concurrent calls from this discussion, then only one of `hash` or the `hashIsZero` fields will have its value changed to a non-default value. i.e. if `hashCode()` implementation computes a non-zero value then the `hash` field will be assigned a (non-default) value and if that method computes a hash of 0, then `hashIsZero` will get assigned a (non-default) value. It then means that the other field will never move out of its initial value and thus will never be considered "stable".
> 
> Am I right? If yes, then would the runtime (hotspot) compiler still replace the call to `String.hashCode()` with a constant value?

Also re @jaikiran: yes, you are right that the current code cannot constant-fold the scenario where the hash is 0; so `"".hashCode()` is not constant as a result. The solution I shared above can address this scenario, but it cannot completely bring performance to parity with other constant-folded cases in Remi's shared benchmark (see https://github.com/liachmodded/jdk/commit/247e8bd92e6dbad6df2dd50ad83caa49983a81b4)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24625#issuecomment-2802495436

From liach at openjdk.org  Mon Apr 14 18:15:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Apr 2025 18:15:48 GMT
Subject: RFR: 8354111: JavaDoc states that Iterator.remove() is linear in
 the LinkedBlockingDeque
In-Reply-To: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
References: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
Message-ID: 

On Tue, 8 Apr 2025 08:50:37 GMT, kabutz  wrote:

> One of the features of the LinkedBlockingDeque is that it is a doubly-linked node queue, with pointers in each node to "prev" and "next", which allows remove() in the Iterator to remove the node in constant time. However, in the JavaDoc of the class, it lists Iterator.remove() as an example of a method that takes linear time.

Looks good, This file has no copyright year so doesn't need a header update. @stuart-marks mind leaving an approval too since you have reviewed the CSR?

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24500#pullrequestreview-2765195813

From liach at openjdk.org  Mon Apr 14 18:17:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Apr 2025 18:17:52 GMT
Subject: RFR: 8354053: Remove unused JavaIOFilePermissionAccess [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 14 Apr 2025 16:14:03 GMT, Roger Riggs  wrote:

>> The JavaIOFilePermissionAccess interface is removed from SharedSecrets and its implementation (FilePermCompat.java) used by the test is moved to java.io FilePermission where cross package access is not needed. 
>> The test FilePermissionCollectionMerge is updated to access the internal implementation in FilePermission. 
>> Modernized the initialization from the system property `jdk.io.permissionsUseCanonicalPath`. 
>> The remaining support will be removed when FilePermission is removed.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify as suggested in review comments
>   Convert static methods to instance methods and invoke on the existing FilePermission.

Looks good to me but need other engineers to review security related aspects.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24603#pullrequestreview-2765200561

From mli at openjdk.org  Mon Apr 14 20:20:44 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 14 Apr 2025 20:20:44 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L [v8]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 14 Apr 2025 03:24:18 GMT, Feilong Jiang  wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minors
>
> Looks good. Thanks!

Thank you @feilongjiang @RealFYang !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24490#issuecomment-2802886830

From mli at openjdk.org  Mon Apr 14 20:20:45 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 14 Apr 2025 20:20:45 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L [v8]
In-Reply-To: <3i70nNWVi7q00e_Y7s5AfP2TdXtkWx79yuHPbFLWBLM=.a01717ba-c6fb-4f0d-a7e0-4b676fcce9bc@github.com>
References: 
 
 <3i70nNWVi7q00e_Y7s5AfP2TdXtkWx79yuHPbFLWBLM=.a01717ba-c6fb-4f0d-a7e0-4b676fcce9bc@github.com>
Message-ID: 

On Mon, 14 Apr 2025 06:26:10 GMT, Fei Yang  wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minors
>
> test/hotspot/jtreg/compiler/lib/ir_framework/TestFramework.java line 149:
> 
>> 147:                     "UseZbb",
>> 148:                     "UseZfh",
>> 149:                     "UseZicond",
> 
> Is this used anywhere?

Yes, when testing both on and off cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24490#discussion_r2042868959

From ron.pressler at oracle.com  Mon Apr 14 20:30:40 2025
From: ron.pressler at oracle.com (Ron Pressler)
Date: Mon, 14 Apr 2025 20:30:40 +0000
Subject: My experience using Java to do CLI Scripting
In-Reply-To: <0be34f61-8b4b-494d-bb4a-2d21fb3127e7@gmail.com>
References: 
 <356624F4-6FE4-4D22-92EE-049C1E03472C@oracle.com>
 <0be34f61-8b4b-494d-bb4a-2d21fb3127e7@gmail.com>
Message-ID: <1E97A470-8441-4DF6-B266-CE45956075F2@oracle.com>

(moved from amber-dev)

Hi.

This does what you want (and could even be combined to a single expression):

    Process p = new ProcessBuilder("ls", "-al").start();
    String result = p.inputReader().lines().collect(Collectors.joining("\n"));

and it?s even nicer in the cases where you may want to process the output line by line, as many scripts do.

Now, does that code deserve its own method in the JDK? Isn?t it about as common to want to process line by line as they?re output by the process? Isn?t it also quite common to care about the standard error? Isn?t such a method short enough to be declared in a script?

But let?s see what we?re left with if we just remove the accidental complexity in the code above, which, I think, is mostly in `.lines` and `Collectors.joining("\n?)`. Imagine (and this is not a proposal, just a thought) we had  `Process.inputLines()` that returns `inputReader().lines()` and a `Collectors.joiningLines()`, and the code would look like this:

    Process p = new ProcessBuilder("ls", "-al").start();
    String result = p.inputLines().collect(Collectors.joiningLines());

I think that be almost as succinct as your API without giving up any flexibility. The only accidental complexity remaining here, I think, is the call to `start` (which can?t be removed if you're interested in the standard error).

Some ideas floated in the ?on ramp? area (although in this case we?re talking about script-writers rather than Java beginners) focus on combining acquiring data and aggregating/parsing it, and I just don?t know how useful that is, given how easily things can be composed.

? Ron



> On 14 Apr 2025, at 20:06, Cay Horstmann  wrote:
> 
> Absolutely, ProcessBuilder/Process is the right approach.
> 
> I realize that all those bells and whistles in the Process API are there for a reason, but the API is a bit clunky for the happy day path that one usually has in a script: running a process until it terminates and getting its output. It is trivial to write a couple of helper methods, but it might be nice if the Process API could help out. Something like
> 
> Process p = Process.waitFor("ls", "-al");
> String result = p.output();
> 
> Cheers,
> 
> Cay
> 
> PS. This isn't pretty in Python either: https://docs.python.org/3/library/subprocess.html#subprocess.run
> 
> 
> Il 12/04/25 17:02, Ron Pressler ha scritto:
>> Hi.
>> Let?s focus on ProcessBuilder and Process (as I think that?s where you want to focus, and why I think this discussion is more appropriate for core-libs-dev). Can you try to show more concretely what the pain point is in your actual code?
>> The ProcessBuilder example is long because it does multiple things, each of which may or may not be relevant to your use case. That doing five different things requires five lines of code doesn?t help us see where your specific pain point is.
>> ? Ron
>>> On 12 Apr 2025, at 15:39, David Alayachew  wrote:
>>> 
>>> Hello Amber Dev Team and Kulla Dev Team,
>>> 
>>> (I made a reddit post too, if you prefer to interact there instead -- https://www.reddit.com/r/java/comments/1jx87ys/)
>>> The following JEP's have released recently.
>>>     ? JEP 495: Simple Source Files and Instance Main Methods
>>>     ? JEP 330: Launch Single-File Source-Code Programs
>>>     ? JEP 222: jshell: The Java Shell (Read-Eval-Print Loop)
>>> These have made it really easy for me to do CLI scripting in Java, as opposed to Bash. However, I've run into some pain points, as I've relied more and more on Java.
>>> For starters, the hand off from Java --> Bash is kind of ugly. Bash --> Java is not bad, due to void main(final String[] args), as well as Bash's xargs. But Java --> Bash is ugly, and here is an example demonstrating how/why.
>>> I use AWS CLI to manage my dev environment. It's super powerful, and is all available directly from the CLI, using simple Bash or even CMD.
>>> Let's say I use AWS CLI to gather some ad-hoc information about my entire dev environment. How do I manage the multiple handoffs back and forth between AWS CLI and Java?
>>> There are no good answers.
>>>     ? Store the results into a file, then use JShell/java(c) to process the output file from Bash/AWS CLI.
>>>         ? There's multiple handoffs back and forth between AWS CLI and Java. So, every handoff from Java ---> AWS CLI means generating a new file, thus increasing the complexity and cruft. It's unideal.
>>>     ? Use Java's ProcessBuilder and Process classes.
>>>         ? This works, but is heavy-handed. Look at the examples in those links. That is multiple lines of code to represent a single bash command. It does appear to be the idiomatic way, though.
>>>     ? Do all upstream processing with AWS CLI in Bash directly, then do only a single handoff to Java, once I have done all I need to with AWS CLI.
>>>         ? This is definitely the least painful, but it also means I don't use much Java at all. And any changes in upstream processing must be done in Bash to avoid handoff headaches from AWS CLI ---> Java.
>>>     ? Download the AWS SDK Jar files and just do it all in Java.
>>>         ? Ignoring the fact that some things are much harder to do via the AWS Java SDK's, there's actually some functionality that just isn't available via the Java ones. I'd have to recreate it myself, and it would be a significant lift.
>>> Option 4 is best when I am building an application, but for ad-hoc checks that I want to do on the fly (my most common use-case by far), I have been using Option 3.
>>> I just wish I could use more Java. It's a FAR BETTERtool than Bash, but I can't justify the level of effort for ad-hoc use cases because of the poor hand off from Java --> Bash. And since AWS CLI is only available via Bash/CMD, I'm stuck with a bunch of not-good choices.
>>> CLI Scripting in Java is great, but I wanted to highlight this pain point to spread awareness.
>>> Can you relate?
>>> 
> 
> -- 
> 
> Cay S. Horstmann | https://horstmann.com
> 


From forax at univ-mlv.fr  Mon Apr 14 20:48:40 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 14 Apr 2025 22:48:40 +0200 (CEST)
Subject: My experience using Java to do CLI Scripting
In-Reply-To: <1E97A470-8441-4DF6-B266-CE45956075F2@oracle.com>
References: 
 <356624F4-6FE4-4D22-92EE-049C1E03472C@oracle.com>
 <0be34f61-8b4b-494d-bb4a-2d21fb3127e7@gmail.com>
 <1E97A470-8441-4DF6-B266-CE45956075F2@oracle.com>
Message-ID: <778403719.226536541.1744663720524.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Ron Pressler" 
> To: "cay horstmann" 
> Cc: "core-libs-dev" , "David Alayachew" 
> Sent: Monday, April 14, 2025 10:30:40 PM
> Subject: Re: My experience using Java to do CLI Scripting

> (moved from amber-dev)
> 
> Hi.
> 
> This does what you want (and could even be combined to a single expression):
> 
>    Process p = new ProcessBuilder("ls", "-al").start();
>    String result = p.inputReader().lines().collect(Collectors.joining("\n"));
> 
> and it?s even nicer in the cases where you may want to process the output line
> by line, as many scripts do.

Hi Ron,
i think you need to close the inputReader

  public static String output(String... args) {
    ProcessBuilder processBuilder = new ProcessBuilder(args);
    try {
      Process process = processBuilder.start();
      try (BufferedReader reader = process.inputReader()) {
        return reader.lines().collect(Collectors.joining("\n"));
      }
    } catch (IOException e) {
      throw new IOError(e);
    }
  }


> 
> ? Ron
> 

regards,
R?mi

> 
> 
>> On 14 Apr 2025, at 20:06, Cay Horstmann  wrote:
>> 
>> Absolutely, ProcessBuilder/Process is the right approach.
>> 
>> I realize that all those bells and whistles in the Process API are there for a
>> reason, but the API is a bit clunky for the happy day path that one usually has
>> in a script: running a process until it terminates and getting its output. It
>> is trivial to write a couple of helper methods, but it might be nice if the
>> Process API could help out. Something like
>> 
>> Process p = Process.waitFor("ls", "-al");
>> String result = p.output();
>> 
>> Cheers,
>> 
>> Cay
>> 
>> PS. This isn't pretty in Python either:
>> https://docs.python.org/3/library/subprocess.html#subprocess.run
>> 
>> 
>> Il 12/04/25 17:02, Ron Pressler ha scritto:
>>> Hi.
>>> Let?s focus on ProcessBuilder and Process (as I think that?s where you want to
>>> focus, and why I think this discussion is more appropriate for core-libs-dev).
>>> Can you try to show more concretely what the pain point is in your actual code?
>>> The ProcessBuilder example is long because it does multiple things, each of
>>> which may or may not be relevant to your use case. That doing five different
>>> things requires five lines of code doesn?t help us see where your specific pain
>>> point is.
>>> ? Ron
>>>> On 12 Apr 2025, at 15:39, David Alayachew  wrote:
>>>> 
>>>> Hello Amber Dev Team and Kulla Dev Team,
>>>> 
>>>> (I made a reddit post too, if you prefer to interact there instead --
>>>> https://www.reddit.com/r/java/comments/1jx87ys/)
>>>> The following JEP's have released recently.
>>>>     ? JEP 495: Simple Source Files and Instance Main Methods
>>>>     ? JEP 330: Launch Single-File Source-Code Programs
>>>>     ? JEP 222: jshell: The Java Shell (Read-Eval-Print Loop)
>>>> These have made it really easy for me to do CLI scripting in Java, as opposed to
>>>> Bash. However, I've run into some pain points, as I've relied more and more on
>>>> Java.
>>>> For starters, the hand off from Java --> Bash is kind of ugly. Bash --> Java is
>>>> not bad, due to void main(final String[] args), as well as Bash's xargs. But
>>>> Java --> Bash is ugly, and here is an example demonstrating how/why.
>>>> I use AWS CLI to manage my dev environment. It's super powerful, and is all
>>>> available directly from the CLI, using simple Bash or even CMD.
>>>> Let's say I use AWS CLI to gather some ad-hoc information about my entire dev
>>>> environment. How do I manage the multiple handoffs back and forth between AWS
>>>> CLI and Java?
>>>> There are no good answers.
>>>>     ? Store the results into a file, then use JShell/java(c) to process the output
>>>>     file from Bash/AWS CLI.
>>>>         ? There's multiple handoffs back and forth between AWS CLI and Java. So, every
>>>>         handoff from Java ---> AWS CLI means generating a new file, thus increasing the
>>>>         complexity and cruft. It's unideal.
>>>>     ? Use Java's ProcessBuilder and Process classes.
>>>>         ? This works, but is heavy-handed. Look at the examples in those links. That is
>>>>         multiple lines of code to represent a single bash command. It does appear to be
>>>>         the idiomatic way, though.
>>>>     ? Do all upstream processing with AWS CLI in Bash directly, then do only a
>>>>     single handoff to Java, once I have done all I need to with AWS CLI.
>>>>         ? This is definitely the least painful, but it also means I don't use much Java
>>>>         at all. And any changes in upstream processing must be done in Bash to avoid
>>>>         handoff headaches from AWS CLI ---> Java.
>>>>     ? Download the AWS SDK Jar files and just do it all in Java.
>>>>         ? Ignoring the fact that some things are much harder to do via the AWS Java
>>>>         SDK's, there's actually some functionality that just isn't available via the
>>>>         Java ones. I'd have to recreate it myself, and it would be a significant lift.
>>>> Option 4 is best when I am building an application, but for ad-hoc checks that I
>>>> want to do on the fly (my most common use-case by far), I have been using
>>>> Option 3.
>>>> I just wish I could use more Java. It's a FAR BETTERtool than Bash, but I can't
>>>> justify the level of effort for ad-hoc use cases because of the poor hand off
>>>> from Java --> Bash. And since AWS CLI is only available via Bash/CMD, I'm stuck
>>>> with a bunch of not-good choices.
>>>> CLI Scripting in Java is great, but I wanted to highlight this pain point to
>>>> spread awareness.
>>>> Can you relate?
>>>> 
>> 
>> --
>> 
>> Cay S. Horstmann | https://horstmann.com

From joehw at openjdk.org  Mon Apr 14 21:00:22 2025
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 14 Apr 2025 21:00:22 GMT
Subject: RFR: 8354084: Streamline XPath API's extension function control
 [v3]
In-Reply-To: <2h00m7NTlmM0pu-x7bRU7_UfgKkS2WVJ4jUEF3hnkzo=.a48773d0-d6e6-4505-8511-76902957b9eb@github.com>
References: <2h00m7NTlmM0pu-x7bRU7_UfgKkS2WVJ4jUEF3hnkzo=.a48773d0-d6e6-4505-8511-76902957b9eb@github.com>
Message-ID: <0y0IinbBL-kjyu8eELDF1VqcJ_s7cChpMss0MNuua2w=.5640dfbf-98c4-44e6-b9f4-053bf8a5fb84@github.com>

> Streamline the extension function control in the XPath API by relying solely on [XPathFunctionResolver](https://docs.oracle.com/en/java/javase/24/docs/api/java.xml/javax/xml/xpath/XPathFunctionResolver.html), which provides a secure and developer-defined mechanism. Remove the feature FEATURE_SECURE_PROCESSING and jdk.xml.enableExtensionFunctions from the decision path that are redundant with regard to XPath's Extension Functions.
> 
> Note the comment in JAXPExtensionsProvider, starting at  "JAXP 1.3 spec says When ...", was not accurate. Refer to the spec: https://docs.oracle.com/en/java/javase/24/docs/api/java.xml/javax/xml/XMLConstants.html#FEATURE_SECURE_PROCESSING, FSP does not have specific requirement for the XPath functions.
> 
> Tests:
>     Tier1 - 3 passed with regard to this change. There were unrelated/known failures (e.g. bug8329757).
>     JCK passed except the previously reported issue (JCK-7322355).

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  rewind resource files, leave them to L10n resource files update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24605/files
  - new: https://git.openjdk.org/jdk/pull/24605/files/72c138f0..c7ec55a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24605&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24605&range=01-02

  Stats: 80 lines in 10 files changed: 60 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/24605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24605/head:pull/24605

PR: https://git.openjdk.org/jdk/pull/24605

From bpb at openjdk.org  Mon Apr 14 21:11:47 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 14 Apr 2025 21:11:47 GMT
Subject: RFR: 8354450: Using a File with a path containing a trailing space
 should fail when alternative data streams are disabled (win)
Message-ID: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>

In `java.io.WinNTFileSystem::isInvalid`, replace an insufficient test for file path validity with a sufficient test for file path invalidity. Also, add a new test.

-------------

Commit messages:
 - 8354450: Using a File with a path containing a trailing space should fail when alternative data streams are disabled (win)

Changes: https://git.openjdk.org/jdk/pull/24635/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24635&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354450
  Stats: 89 lines in 2 files changed: 82 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24635.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24635/head:pull/24635

PR: https://git.openjdk.org/jdk/pull/24635

From ron.pressler at oracle.com  Mon Apr 14 21:46:25 2025
From: ron.pressler at oracle.com (Ron Pressler)
Date: Mon, 14 Apr 2025 21:46:25 +0000
Subject: [External] : Re: My experience using Java to do CLI Scripting
In-Reply-To: <778403719.226536541.1744663720524.JavaMail.zimbra@univ-eiffel.fr>
References: 
 <356624F4-6FE4-4D22-92EE-049C1E03472C@oracle.com>
 <0be34f61-8b4b-494d-bb4a-2d21fb3127e7@gmail.com>
 <1E97A470-8441-4DF6-B266-CE45956075F2@oracle.com>
 <778403719.226536541.1744663720524.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: 



> On 14 Apr 2025, at 21:48, Remi Forax  wrote:
> 
> 
> Hi Ron,
> i think you need to close the inputReader
> 
>  public static String output(String... args) {
>    ProcessBuilder processBuilder = new ProcessBuilder(args);
>    try {
>      Process process = processBuilder.start();
>      try (BufferedReader reader = process.inputReader()) {
>        return reader.lines().collect(Collectors.joining("\n"));
>      }
>    } catch (IOException e) {
>      throw new IOError(e);
>    }
>  }


When the process terminates, the InputStream underlying the pipe is closed (after being drained and the unread bytes served by a ByteArrayInputStream), which *I think* should be sufficient, but I could be wrong.

? Ron

From stuart.marks at oracle.com  Mon Apr 14 22:10:54 2025
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 14 Apr 2025 15:10:54 -0700
Subject: My experience using Java to do CLI Scripting
In-Reply-To: <778403719.226536541.1744663720524.JavaMail.zimbra@univ-eiffel.fr>
References: 
 <356624F4-6FE4-4D22-92EE-049C1E03472C@oracle.com>
 <0be34f61-8b4b-494d-bb4a-2d21fb3127e7@gmail.com>
 <1E97A470-8441-4DF6-B266-CE45956075F2@oracle.com>
 <778403719.226536541.1744663720524.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <2caec135-cdb2-46d4-b46d-e6979f99b6ae@oracle.com>



On 4/14/25 1:48 PM, Remi Forax wrote:
>> From: "Ron Pressler" 
>> This does what you want (and could even be combined to a single expression):
>>
>>     Process p = new ProcessBuilder("ls", "-al").start();
>>     String result = p.inputReader().lines().collect(Collectors.joining("\n"));
>>
>> and it?s even nicer in the cases where you may want to process the output line
>> by line, as many scripts do.
> 
> Hi Ron,
> i think you need to close the inputReader

A few points here...

It might be possible to get away without any Process-related cleanup. For one, 
there's no "close" method on Process or ProcessBuilder. The destroy() method will 
certainly clean up, but you don't want that; and waitFor() merely waits for 
termination but doesn't actually clean anything up.

At least in the Unix ProcessImpl class, there's a bunch of infrastructure to handle 
exit of the underlying process, drain input from its stdout/stderr, and close the 
pipes. (I didn't look on Windows.) So setting aside termination, IOException, and 
what to do with stderr, it seems possible to just get the inputReader() and do 
something with the characters it emits.

Getting a stream of lines with lines() seems like a reasonable thing to do if you 
want to process the output line by line.

There are other possibilities, taking a nod from Files, which has methods 
readAllLines() and readString(). Putting similar methods on some class in the Reader 
family might help considerably here. Or you could call Reader.transferTo(Writer) 
that will send the characters to any Writer that might have a useful destination.

s'marks





> 
>    public static String output(String... args) {
>      ProcessBuilder processBuilder = new ProcessBuilder(args);
>      try {
>        Process process = processBuilder.start();
>        try (BufferedReader reader = process.inputReader()) {
>          return reader.lines().collect(Collectors.joining("\n"));
>        }
>      } catch (IOException e) {
>        throw new IOError(e);
>      }
>    }
> 
> 
>>
>> ? Ron
>>
> 
> regards,
> R?mi
> 
>>
>>
>>> On 14 Apr 2025, at 20:06, Cay Horstmann  wrote:
>>>
>>> Absolutely, ProcessBuilder/Process is the right approach.
>>>
>>> I realize that all those bells and whistles in the Process API are there for a
>>> reason, but the API is a bit clunky for the happy day path that one usually has
>>> in a script: running a process until it terminates and getting its output. It
>>> is trivial to write a couple of helper methods, but it might be nice if the
>>> Process API could help out. Something like
>>>
>>> Process p = Process.waitFor("ls", "-al");
>>> String result = p.output();
>>>
>>> Cheers,
>>>
>>> Cay
>>>
>>> PS. This isn't pretty in Python either:
>>> https://docs.python.org/3/library/subprocess.html#subprocess.run
>>>
>>>
>>> Il 12/04/25 17:02, Ron Pressler ha scritto:
>>>> Hi.
>>>> Let?s focus on ProcessBuilder and Process (as I think that?s where you want to
>>>> focus, and why I think this discussion is more appropriate for core-libs-dev).
>>>> Can you try to show more concretely what the pain point is in your actual code?
>>>> The ProcessBuilder example is long because it does multiple things, each of
>>>> which may or may not be relevant to your use case. That doing five different
>>>> things requires five lines of code doesn?t help us see where your specific pain
>>>> point is.
>>>> ? Ron
>>>>> On 12 Apr 2025, at 15:39, David Alayachew  wrote:
>>>>>
>>>>> Hello Amber Dev Team and Kulla Dev Team,
>>>>>
>>>>> (I made a reddit post too, if you prefer to interact there instead --
>>>>> https://www.reddit.com/r/java/comments/1jx87ys/)
>>>>> The following JEP's have released recently.
>>>>>      ? JEP 495: Simple Source Files and Instance Main Methods
>>>>>      ? JEP 330: Launch Single-File Source-Code Programs
>>>>>      ? JEP 222: jshell: The Java Shell (Read-Eval-Print Loop)
>>>>> These have made it really easy for me to do CLI scripting in Java, as opposed to
>>>>> Bash. However, I've run into some pain points, as I've relied more and more on
>>>>> Java.
>>>>> For starters, the hand off from Java --> Bash is kind of ugly. Bash --> Java is
>>>>> not bad, due to void main(final String[] args), as well as Bash's xargs. But
>>>>> Java --> Bash is ugly, and here is an example demonstrating how/why.
>>>>> I use AWS CLI to manage my dev environment. It's super powerful, and is all
>>>>> available directly from the CLI, using simple Bash or even CMD.
>>>>> Let's say I use AWS CLI to gather some ad-hoc information about my entire dev
>>>>> environment. How do I manage the multiple handoffs back and forth between AWS
>>>>> CLI and Java?
>>>>> There are no good answers.
>>>>>      ? Store the results into a file, then use JShell/java(c) to process the output
>>>>>      file from Bash/AWS CLI.
>>>>>          ? There's multiple handoffs back and forth between AWS CLI and Java. So, every
>>>>>          handoff from Java ---> AWS CLI means generating a new file, thus increasing the
>>>>>          complexity and cruft. It's unideal.
>>>>>      ? Use Java's ProcessBuilder and Process classes.
>>>>>          ? This works, but is heavy-handed. Look at the examples in those links. That is
>>>>>          multiple lines of code to represent a single bash command. It does appear to be
>>>>>          the idiomatic way, though.
>>>>>      ? Do all upstream processing with AWS CLI in Bash directly, then do only a
>>>>>      single handoff to Java, once I have done all I need to with AWS CLI.
>>>>>          ? This is definitely the least painful, but it also means I don't use much Java
>>>>>          at all. And any changes in upstream processing must be done in Bash to avoid
>>>>>          handoff headaches from AWS CLI ---> Java.
>>>>>      ? Download the AWS SDK Jar files and just do it all in Java.
>>>>>          ? Ignoring the fact that some things are much harder to do via the AWS Java
>>>>>          SDK's, there's actually some functionality that just isn't available via the
>>>>>          Java ones. I'd have to recreate it myself, and it would be a significant lift.
>>>>> Option 4 is best when I am building an application, but for ad-hoc checks that I
>>>>> want to do on the fly (my most common use-case by far), I have been using
>>>>> Option 3.
>>>>> I just wish I could use more Java. It's a FAR BETTERtool than Bash, but I can't
>>>>> justify the level of effort for ad-hoc use cases because of the poor hand off
>>>>> from Java --> Bash. And since AWS CLI is only available via Bash/CMD, I'm stuck
>>>>> with a bunch of not-good choices.
>>>>> CLI Scripting in Java is great, but I wanted to highlight this pain point to
>>>>> spread awareness.
>>>>> Can you relate?
>>>>>
>>>
>>> --
>>>
>>> Cay S. Horstmann | https://horstmann.com


From smarks at openjdk.org  Mon Apr 14 22:27:53 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 14 Apr 2025 22:27:53 GMT
Subject: RFR: 8354464: Additional cleanup setting up native.encoding
Message-ID: 

Remove the #ifdef MACOSX from platform-independent System.c, which (on Mac) sets native.encoding from sprops.encoding or (on non-Mac Unix and Windows) sets native.encoding from sprops.sun_jnu_encoding. After this removal, the native.encoding property will be set from sprops.encoding and the sun.jnu.encoding property will be set from sprops.sun_jnu_encoding.

Change the windows java_props_md.c so that it initializes sprops.sun_jnu_encoding and then copies that value to sprops.encoding. Previously, sprops.encoding was initialized with data from other Windows APIs, but this value was ignored by platform-independent code, which was kind of confusing.

There are no changes to the Unix (Mac & non-Mac) platform-specific code. It already has code to set sprops.encoding and sprops.sun_jnu_encoding properly, including macOS-specific code to set the latter to UTF-8 unconditionally.

There should be no behavior changes on any platform.

I changed variable names in windows/java_props_md.c to make it clear that the values stored into them are unused. Of course there are other possibilities here, such as changing the interface to SetupI18nProps(). I'm open to suggestions.

-------------

Commit messages:
 - Rename variables to make clear they're not used.
 - 8354464: Additional cleanup setting up native.encoding

Changes: https://git.openjdk.org/jdk/pull/24607/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24607&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354464
  Stats: 17 lines in 2 files changed: 2 ins; 12 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24607.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24607/head:pull/24607

PR: https://git.openjdk.org/jdk/pull/24607

From smarks at openjdk.org  Mon Apr 14 22:36:46 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 14 Apr 2025 22:36:46 GMT
Subject: RFR: 8354111: JavaDoc states that Iterator.remove() is linear in
 the LinkedBlockingDeque
In-Reply-To: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
References: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
Message-ID: <6PRVUUkFi99hOPujPjp49IIyU2UXG5eK99d3gejh3Z4=.a44a7d20-2dab-48af-b719-ba0b9871c7e8@github.com>

On Tue, 8 Apr 2025 08:50:37 GMT, kabutz  wrote:

> One of the features of the LinkedBlockingDeque is that it is a doubly-linked node queue, with pointers in each node to "prev" and "next", which allows remove() in the Iterator to remove the node in constant time. However, in the JavaDoc of the class, it lists Iterator.remove() as an example of a method that takes linear time.

LGTM

-------------

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24500#pullrequestreview-2765914410

From hboehm at google.com  Mon Apr 14 23:59:13 2025
From: hboehm at google.com (Hans Boehm)
Date: Mon, 14 Apr 2025 16:59:13 -0700
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, Apr 11, 2025 at 2:39?PM Roger Riggs  wrote:

> On Fri, 11 Apr 2025 20:09:10 GMT, Brent Christian 
> wrote:
>
> test/lib/jdk/test/whitebox/WhiteBox.java line 568:
>
> > 566:   private Method getWaitForReferenceProcessingMethod() {
> > 567:     Method wfrp = waitForReferenceProcessingMethod;
> > 568:     if (wfrp == null) {
>
> Racy initialization is fine, the field can be static and the last one (any
> racy init would all the same) wins:
>
How did you conclude that? From what I can see, Method has non-final
fields.  If another thread reads waitForReferenceProcessingMethod shortly
after it is set, wfrp may be non-null, but its fields may not appear to be
set correctly.

Furthermore, it seems to me there is nothing to stop the compiler from
moving up the assignment to waitForReferenceProcessingMethod.

AFAICT, waitForReferenceProcessingMethod needs to be volatile here. Which
shouldn't matter that much anymore on most modern hardware.

Hans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From iklam at openjdk.org  Tue Apr 15 01:01:08 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 15 Apr 2025 01:01:08 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v6]
In-Reply-To: <-r-008S-HtyyMBystnDKZZUaiCGdbUHSx7v87MeWatA=.02df1f9f-a85e-4136-a1a7-672782415527@github.com>
References: 
 
 
 <-r-008S-HtyyMBystnDKZZUaiCGdbUHSx7v87MeWatA=.02df1f9f-a85e-4136-a1a7-672782415527@github.com>
Message-ID: 

On Mon, 14 Apr 2025 15:23:07 GMT, Timofei Pushkin  wrote:

>> test/hotspot/jtreg/runtime/cds/appcds/customLoader/ClassFromClasspath.java line 53:
>> 
>>> 51:         out.shouldContain("unreg CustomLoadee");
>>> 52:     }
>>> 53: }
>> 
>> For completeness, I think we should have a more complicated scenario:
>> 
>> - load CustomLoadee in both the app loader and a custom loader
>> - load CustomLoadeeChild in the custom loader. Its super class should be the one defined in the custom loader
>> 
>> At run time, verify that CustomLoadeeChild is archived and its super class is defined in the custom loader
>
> This case will work, I've added the test, however I found another case which won't be handled correctly, neither before nor after this change.
> 
> This is the case you've suggested, it works fine both before and after the change.
> 
> java/lang/Object id: 0
> CustomLoadee3 id: 1
> CustomLoadee3 id: 2 super: 0 source: a.jar
> CustomLoadee3Child id: 3 super: 2 source: a.jar
> 
> 
> However the below one doesn't work neither before nor after this change. At dump time, 2 is loaded instead of 1 as the super of 3 because 2, 3 are loaded by the same class loader and 1, 2 have the same name. It is possible to get such class list if 2 is loaded by a non-delegating unregistered loader while 3 is loaded by a different delegating one.
> 
> # Difference with the previous: super of the last class
> java/lang/Object id: 0
> CustomLoadee3 id: 1
> CustomLoadee3 id: 2 super: 0 source: a.jar
> CustomLoadee3Child id: 3 super: 1 source: a.jar
> 
> 
> And the following case is working without this change but will not work with it. It is working now because there will be two different unregistered loaders for classes 2 and 3 (because they have the same source), however with this change there will be one and it will re-use 2 already loaded by it when loading 3.
> 
> # Difference with the previous: source of the last class
> java/lang/Object id: 0
> CustomLoadee3 id: 1
> CustomLoadee3 id: 2 super: 0 source: a.jar
> CustomLoadee3Child id: 3 super: 1 source: b.jar
> 
> 
> Although the last case is a regression, I am not sure how much of a problem this is since in general having a registered super with the same name as another unregistered class is not supported anyway as shown by the second case.

Thanks for doing the investigation. I think we are always going to have some corner cases that cannot be covered:

- For your second case, we would need a separate ClassLoader per class.
- However, that will result in the IllegalAccessError in the current PR

The problem is we are trying to reconstruct the classes without reconstructing the ClassLoaders. A real solution would probably require updating the classlist format.

However, future CDS improvements will be based on the AOT cache introduced in JEP 483. As of JDK 25, we have changed the AOT cache configuration file from a text file (classlist) to a binary file (see https://github.com/openjdk/jdk/pull/23484) . Also, the unregistered classes are saved from the training run, where we still have ClassLoader information (see https://github.com/openjdk/jdk/pull/23926). Therefore, I think we should just leave the old classlist format as is, and accept that certain unregistered classes cannot be supported. I'll try add some test cases ([JDK-8354557](https://bugs.openjdk.org/browse/JDK-8354557)) for the AOT cache using the test cases you identified above.

This PR address the IllegalAccessError problem and simplifies the implementation of classlist handling. However, it causes incompatibility (in your third case). I think we should change the error checking code in `InstanceKlass* ClassListParser::load_class_from_source()` to print a warning message and continue. These are the rare cases that we cannot support. Since CDS is just a cache mechanism, it should be acceptable that certain classes are not supported. We can use your second and third test cases to validate the warning messages.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2043259660

From duke at openjdk.org  Tue Apr 15 02:43:40 2025
From: duke at openjdk.org (duke)
Date: Tue, 15 Apr 2025 02:43:40 GMT
Subject: RFR: 8354111: JavaDoc states that Iterator.remove() is linear in
 the LinkedBlockingDeque
In-Reply-To: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
References: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
Message-ID: <5sisd8xKwrPB0EF5aV6M5aHLKfWlXl7SGe7MH4gGymw=.b9ded49b-60cc-4587-be40-401bc40a0064@github.com>

On Tue, 8 Apr 2025 08:50:37 GMT, kabutz  wrote:

> One of the features of the LinkedBlockingDeque is that it is a doubly-linked node queue, with pointers in each node to "prev" and "next", which allows remove() in the Iterator to remove the node in constant time. However, in the JavaDoc of the class, it lists Iterator.remove() as an example of a method that takes linear time.

@kabutz 
Your change (at version 917c851a68e7cc52c153c0de5030cd65dc8397c9) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24500#issuecomment-2803601061

From liach at openjdk.org  Tue Apr 15 02:50:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Apr 2025 02:50:51 GMT
Subject: RFR: 8354111: JavaDoc states that Iterator.remove() is linear in
 the LinkedBlockingDeque
In-Reply-To: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
References: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
Message-ID: <8qCRJNas06IY00xZejTUQQxaXFIPTEDRiaz5seC0oyw=.57881a96-ccf3-47c3-bd84-6980f6e978d2@github.com>

On Tue, 8 Apr 2025 08:50:37 GMT, kabutz  wrote:

> One of the features of the LinkedBlockingDeque is that it is a doubly-linked node queue, with pointers in each node to "prev" and "next", which allows remove() in the Iterator to remove the node in constant time. However, in the JavaDoc of the class, it lists Iterator.remove() as an example of a method that takes linear time.

Thanks for the fix!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24500#issuecomment-2803613891

From duke at openjdk.org  Tue Apr 15 02:50:52 2025
From: duke at openjdk.org (kabutz)
Date: Tue, 15 Apr 2025 02:50:52 GMT
Subject: Integrated: 8354111: JavaDoc states that Iterator.remove() is linear
 in the LinkedBlockingDeque
In-Reply-To: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
References: <4_156-5ohd5i02vZTcahA8l1VhT0mGxae5evwjVGzTs=.36898d4f-5ddb-441e-ab5a-fa8827e4484d@github.com>
Message-ID: 

On Tue, 8 Apr 2025 08:50:37 GMT, kabutz  wrote:

> One of the features of the LinkedBlockingDeque is that it is a doubly-linked node queue, with pointers in each node to "prev" and "next", which allows remove() in the Iterator to remove the node in constant time. However, in the JavaDoc of the class, it lists Iterator.remove() as an example of a method that takes linear time.

This pull request has now been integrated.

Changeset: c7b70a13
Author:    Dr Heinz M. Kabutz 
Committer: Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/c7b70a138ff592fdf1cd4f1d063103491a8aa7db
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8354111: JavaDoc states that Iterator.remove() is linear in the LinkedBlockingDeque

Reviewed-by: liach, smarks

-------------

PR: https://git.openjdk.org/jdk/pull/24500

From liach at openjdk.org  Tue Apr 15 03:30:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Apr 2025 03:30:00 GMT
Subject: RFR: 8354076: LinkedBlockingDeque offer() creates nodes even if
 capacity has been reached
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 18:39:30 GMT, kabutz  wrote:

> In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking.
> 
> In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field.
> 
> Our suggestion is to make count volatile, and then exiting early from poll() and offer()

If we strictly adhere to this interpretation of "create nodes", then we must only call a constructor after the locked capacity check has passed in places like `offerLast`, and this patch has not accomplished that yet.

I think the correct way to interpret the spec here is that "create node" means a node is created in the linked list, so we can interpret that as a change in collection membership reflected in accessor methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24521#issuecomment-2803675483

From kbarrett at openjdk.org  Tue Apr 15 05:46:46 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 15 Apr 2025 05:46:46 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 15 Apr 2025 00:00:35 GMT, Hans Boehm  wrote:

> > Racy initialization is fine, the field can be static and the last one (any
> > racy init would all the same) wins:
> 
> How did you conclude that? From what I can see, Method has non-final fields. If another thread reads waitForReferenceProcessingMethod shortly after it is set, wfrp may be non-null, but its fields may not appear to be set correctly.
> 
> Furthermore, it seems to me there is nothing to stop the compiler from moving up the assignment to waitForReferenceProcessingMethod.
> 
> AFAICT, waitForReferenceProcessingMethod needs to be volatile here. Which shouldn't matter that much anymore on most modern hardware.

Agreed.  I'm pretty sure that all of the places I know of where I want to use
this are single-threaded, but being cautious is better.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24527#issuecomment-2803873414

From jpai at openjdk.org  Tue Apr 15 05:57:19 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 15 Apr 2025 05:57:19 GMT
Subject: RFR: 8354565: jtreg failure handler GatherProcessInfoTimeoutHandler
 has a leftover call to System.loadLibrary
Message-ID: 

Can I please get a review of this cleanup in the jtreg timeout handler `GatherProcessInfoTimeoutHandler`?

As noted in https://bugs.openjdk.org/browse/JDK-8354565, this is a leftover after the change done in https://bugs.openjdk.java.net/browse/JDK-8268626. The `timeoutHandler` native test library is no longer built in the JDK, nor it is required by this `GatherProcessInfoTimeoutHandler`. 

I've verified that the `GatherProcessInfoTimeoutHandler` continues to function normally on macosx (x64/aarch64), linux(x64/aarch64) and windows (x64), by intentionally timing out a test and verifying that the `GatherProcessInfoTimeoutHandler` continues to gather the relevant diagnostics.

-------------

Commit messages:
 - 8354565: jtreg failure handler GatherProcessInfoTimeoutHandler has a leftover call to System.loadLibrary

Changes: https://git.openjdk.org/jdk/pull/24648/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24648&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354565
  Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24648.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24648/head:pull/24648

PR: https://git.openjdk.org/jdk/pull/24648

From alanb at openjdk.org  Tue Apr 15 06:00:39 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Apr 2025 06:00:39 GMT
Subject: RFR: 8354565: jtreg failure handler
 GatherProcessInfoTimeoutHandler has a leftover call to System.loadLibrary
In-Reply-To: 
References: 
Message-ID: 

On Tue, 15 Apr 2025 05:50:03 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this cleanup in the jtreg timeout handler `GatherProcessInfoTimeoutHandler`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8354565, this is a leftover after the change done in https://bugs.openjdk.java.net/browse/JDK-8268626. The `timeoutHandler` native test library is no longer built in the JDK, nor it is required by this `GatherProcessInfoTimeoutHandler`. 
> 
> I've verified that the `GatherProcessInfoTimeoutHandler` continues to function normally on macosx (x64/aarch64), linux(x64/aarch64) and windows (x64), by intentionally timing out a test and verifying that the `GatherProcessInfoTimeoutHandler` continues to gather the relevant diagnostics.

Good

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24648#pullrequestreview-2766888348

From kbarrett at openjdk.org  Tue Apr 15 06:03:40 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 15 Apr 2025 06:03:40 GMT
Subject: RFR: 8354565: jtreg failure handler
 GatherProcessInfoTimeoutHandler has a leftover call to System.loadLibrary
In-Reply-To: 
References: 
Message-ID: 

On Tue, 15 Apr 2025 05:50:03 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this cleanup in the jtreg timeout handler `GatherProcessInfoTimeoutHandler`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8354565, this is a leftover after the change done in https://bugs.openjdk.java.net/browse/JDK-8268626. The `timeoutHandler` native test library is no longer built in the JDK, nor it is required by this `GatherProcessInfoTimeoutHandler`. 
> 
> I've verified that the `GatherProcessInfoTimeoutHandler` continues to function normally on macosx (x64/aarch64), linux(x64/aarch64) and windows (x64), by intentionally timing out a test and verifying that the `GatherProcessInfoTimeoutHandler` continues to gather the relevant diagnostics.

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24648#pullrequestreview-2766895709

From duke at openjdk.org  Tue Apr 15 06:20:41 2025
From: duke at openjdk.org (kabutz)
Date: Tue, 15 Apr 2025 06:20:41 GMT
Subject: RFR: 8354076: LinkedBlockingDeque offer() creates nodes even if
 capacity has been reached
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 18:39:30 GMT, kabutz  wrote:

> In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking.
> 
> In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field.
> 
> Our suggestion is to make count volatile, and then exiting early from poll() and offer()

My code is similar to how LinkedBlockingQueue works.

>From LinkedBlockingQueue:


    public boolean offer(E e) {
        if (e == null) throw new NullPointerException();
        final AtomicInteger count = this.count;
        if (count.get() == capacity)
            return false;
        final int c;
        final Node node = new Node(e);
        final ReentrantLock putLock = this.putLock;
        putLock.lock();
        try {
            if (count.get() == capacity)
                return false;
            enqueue(node);
            c = count.getAndIncrement();
            if (c + 1 < capacity)
                notFull.signal();
        } finally {
            putLock.unlock();
        }
        if (c == 0)
            signalNotEmpty();
        return true;
    }


However, I'm not sure whether it is a good idea to make this change, since making count volatile in LBD might impact performance for the most common use case (unbounded deque). For example:


import java.util.*;
import java.util.concurrent.*;
import java.util.stream.*;

public class NodeCreationBeforeLockLBD {
    /*
      This tests how quickly we can offer and poll on an "unbounded" deque,
      in order to see whether it is better to create the node before the lock.
     */

    public static void main(String... args) {
        for (int i = 0; i < 3; i++) {
            test(new LinkedBlockingDeque<>());
        }
    }

    private static void test(Queue q) {
        System.out.println(q.getClass().getSimpleName());
        long time = System.nanoTime();
        try {
            IntStream.range(0, 10_000_000)
                    .parallel()
                    .forEach(i -> {
                        for (int j = 0; j < 5; j++) q.offer(j);
                        for (int j = 0; j < 5; j++) q.poll();
                    });
            System.out.println("q = " + q);
        } finally {
            time = System.nanoTime() - time;
            System.out.printf("time = %dms%n", (time / 1_000_000));
        }
    }
}


Output with Java 25+17:


$ java -showversion NodeCreationBeforeLockLBD.java
openjdk version "25-ea" 2025-09-16
OpenJDK Runtime Environment (build 25-ea+17-1966)
OpenJDK 64-Bit Server VM (build 25-ea+17-1966, mixed mode, sharing)
LinkedBlockingDeque
q = []
time = 4790ms
LinkedBlockingDeque
q = []
time = 4411ms
LinkedBlockingDeque
q = []
time = 4588ms


Output with these changes:


$ java -showversion NodeCreationBeforeLockLBD.java
openjdk version "25-internal" 2025-09-16
OpenJDK Runtime Environment (build 25-internal-adhoc.kabutz.jdk)
OpenJDK 64-Bit Server VM (build 25-internal-adhoc.kabutz.jdk, mixed mode)
LinkedBlockingDeque
q = []
time = 6436ms
LinkedBlockingDeque
q = []
time = 5871ms
LinkedBlockingDeque
q = []
time = 5982ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24521#issuecomment-2803938784

From alanb at openjdk.org  Tue Apr 15 06:36:20 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Apr 2025 06:36:20 GMT
Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth
 Preview) [v8]
In-Reply-To: 
References: 
Message-ID: 

> Changes for [JEP 505: Structured Concurrency (Fifth Preview)](https://openjdk.org/jeps/8340343). The proposal is to re-preview the API with some changes, specifically:
> 
> - A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor.  Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close.
> - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner.
> - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions.
> - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function.
> - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method.
>  
> The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Add JEP number, update copyright headers
 - Merge branch 'master' into JDK-8342486
 - Sync up from loom repo
 - Merge branch 'master' into JDK-8342486
 - Sync up from loom repo
 - Merge branch 'master' into JDK-8342486
 - Merge branch 'master' into JDK-8342486
 - Fix link
 - Merge branch 'master' into JDK-8342486
 - Sync up impl/tests form loom repo
 - ... and 5 more: https://git.openjdk.org/jdk/compare/3090e218...418bc3d3

-------------

Changes: https://git.openjdk.org/jdk/pull/21934/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21934&range=07
  Stats: 4087 lines in 14 files changed: 1862 ins; 1447 del; 778 mod
  Patch: https://git.openjdk.org/jdk/pull/21934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21934/head:pull/21934

PR: https://git.openjdk.org/jdk/pull/21934

From alanb at openjdk.org  Tue Apr 15 06:36:21 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Apr 2025 06:36:21 GMT
Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth
 Preview) [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 08:14:52 GMT, Alan Bateman  wrote:

>> Changes for [JEP 505: Structured Concurrency (Fifth Preview)](https://openjdk.org/jeps/8340343). The proposal is to re-preview the API with some changes, specifically:
>> 
>> - A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor.  Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close.
>> - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner.
>> - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions.
>> - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function.
>> - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method.
>>  
>> The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Sync up from loom repo
>  - Merge branch 'master' into JDK-8342486
>  - Sync up from loom repo
>  - Merge branch 'master' into JDK-8342486
>  - Merge branch 'master' into JDK-8342486
>  - Fix link
>  - Merge branch 'master' into JDK-8342486
>  - Sync up impl/tests form loom repo
>  - Merge branch 'master' into JDK-8342486
>  - Pull latest API docs + impl from loom repo
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/d8bed693...0ca374ed

Re-opening as skara bot closed it again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21934#issuecomment-2803962858

From cay.horstmann at gmail.com  Tue Apr 15 06:52:06 2025
From: cay.horstmann at gmail.com (Cay Horstmann)
Date: Tue, 15 Apr 2025 08:52:06 +0200
Subject: [External] : Re: My experience using Java to do CLI Scripting
In-Reply-To: 
References: 
 <356624F4-6FE4-4D22-92EE-049C1E03472C@oracle.com>
 <0be34f61-8b4b-494d-bb4a-2d21fb3127e7@gmail.com>
 <1E97A470-8441-4DF6-B266-CE45956075F2@oracle.com>
 <778403719.226536541.1744663720524.JavaMail.zimbra@univ-eiffel.fr>
 
Message-ID: 



Il 14/04/25 23:46, Ron Pressler ha scritto:
> 
> 
>> On 14 Apr 2025, at 21:48, Remi Forax  wrote:
>>
>>
>> Hi Ron,
>> i think you need to close the inputReader
>>
>>   public static String output(String... args) {
>>     ProcessBuilder processBuilder = new ProcessBuilder(args);
>>     try {
>>       Process process = processBuilder.start();
>>       try (BufferedReader reader = process.inputReader()) {
>>         return reader.lines().collect(Collectors.joining("\n"));
>>       }
>>     } catch (IOException e) {
>>       throw new IOError(e);
>>     }
>>   }
> 
> 
> When the process terminates, the InputStream underlying the pipe is closed (after being drained and the unread bytes served by a ByteArrayInputStream), which *I think* should be sufficient, but I could be wrong.
> 
> ? Ron

Reading the process output into a string or string stream raises a number of worries.

* Do I need to wait for the process to complete?
* Do I need to close anything?
* How exactly do I use getInputStream()/inputReader() with *extreme care*, as the API doc warns me?

If it is safe to call

   builder.start().inputReader().lines()

or

   builder.start().getInputStream().readAllBytes()

without waiting or closing, then the API doc could say so. If not, then maybe a safe method to get the entire output would be appropriate for Process?


-- 

Cay S. Horstmann | https://horstmann.com


From ecki at zusammenkunft.net  Tue Apr 15 08:41:41 2025
From: ecki at zusammenkunft.net (Bernd)
Date: Tue, 15 Apr 2025 10:41:41 +0200
Subject: [External] : Re: My experience using Java to do CLI Scripting
In-Reply-To: 
References: 
 <356624F4-6FE4-4D22-92EE-049C1E03472C@oracle.com>
 <0be34f61-8b4b-494d-bb4a-2d21fb3127e7@gmail.com>
 <1E97A470-8441-4DF6-B266-CE45956075F2@oracle.com>
 <778403719.226536541.1744663720524.JavaMail.zimbra@univ-eiffel.fr>
 ,
 
Message-ID: <84C8F504-FE96-8C47-8AA6-36719613FA96@hxcore.ol>

An HTML attachment was scrubbed...
URL: 

From xgong at openjdk.org  Tue Apr 15 09:32:49 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 15 Apr 2025 09:32:49 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 21:23:52 GMT, Vladimir Ivanov  wrote:

>> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
>> 
>> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
>> 
>> The patch consists of the following parts:
>>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
>> 
>> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
>> 
>> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
>> 
>> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
>> 
>> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
>> 
>> Thanks!
>
> Vladimir Ivanov 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 19 additional commits since the last revision:
> 
>  - Merge branch 'master' into vector.math.01.java
>  - RVV and SVE adjustments
>  - Merge branch 'master' into vector.math.01.java
>  - Fix windows-aarch64 build failure
>  - features_string -> cpu_info_string
>  - Reviews and Float64Vector-related fix
>  - Misc fixes and cleanups
>  - CPU features support
>  - Cleanup
>  - TODO list
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/6e3fd4ab...0ffed12f

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 198:

> 196:             if (vspecies.vectorBitSize() < 128) {
> 197:                 return false; // 64-bit vectors are not supported
> 198:             }

Thanks for your refactor. It's really a good job!  

It seems float type support 64-bit vector operations before (see https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp#L9835). Will this change the behavior of 64-bit float vector? Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2044095931

From forax at univ-mlv.fr  Tue Apr 15 09:44:08 2025
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 15 Apr 2025 11:44:08 +0200 (CEST)
Subject: [External] : Re: My experience using Java to do CLI Scripting
In-Reply-To: 
References: 
 <356624F4-6FE4-4D22-92EE-049C1E03472C@oracle.com>
 <0be34f61-8b4b-494d-bb4a-2d21fb3127e7@gmail.com>
 <1E97A470-8441-4DF6-B266-CE45956075F2@oracle.com>
 <778403719.226536541.1744663720524.JavaMail.zimbra@univ-eiffel.fr>
 
Message-ID: <1773315462.227167919.1744710248555.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Ron Pressler" 
> To: "Remi Forax" 
> Cc: "cay horstmann" , "core-libs-dev" , "David Alayachew"
> 
> Sent: Monday, April 14, 2025 11:46:25 PM
> Subject: Re: [External] : Re: My experience using Java to do CLI Scripting

>> On 14 Apr 2025, at 21:48, Remi Forax  wrote:
>> 
>> 
>> Hi Ron,
>> i think you need to close the inputReader
>> 
>>  public static String output(String... args) {
>>    ProcessBuilder processBuilder = new ProcessBuilder(args);
>>    try {
>>      Process process = processBuilder.start();
>>      try (BufferedReader reader = process.inputReader()) {
>>        return reader.lines().collect(Collectors.joining("\n"));
>>      }
>>    } catch (IOException e) {
>>      throw new IOError(e);
>>    }
>>  }
> 
> 
> When the process terminates, the InputStream underlying the pipe is closed
> (after being drained and the unread bytes served by a ByteArrayInputStream),
> which *I think* should be sufficient, but I could be wrong.

I more worried about the iterator used by lines() throwing an exception (IO or charset related) or joining() throwing an OOME because in that case the reader may not be closed.

> 
> ? Ron

regards,
R?mi

From forax at univ-mlv.fr  Tue Apr 15 09:51:07 2025
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 15 Apr 2025 11:51:07 +0200 (CEST)
Subject: My experience using Java to do CLI Scripting
In-Reply-To: <2caec135-cdb2-46d4-b46d-e6979f99b6ae@oracle.com>
References: 
 <356624F4-6FE4-4D22-92EE-049C1E03472C@oracle.com>
 <0be34f61-8b4b-494d-bb4a-2d21fb3127e7@gmail.com>
 <1E97A470-8441-4DF6-B266-CE45956075F2@oracle.com>
 <778403719.226536541.1744663720524.JavaMail.zimbra@univ-eiffel.fr>
 <2caec135-cdb2-46d4-b46d-e6979f99b6ae@oracle.com>
Message-ID: <1168340462.227175047.1744710667933.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Stuart Marks" 
> To: "Remi Forax" , "Ron Pressler" , "David Alayachew"
> 
> Cc: "cay horstmann" , "core-libs-dev" 
> Sent: Tuesday, April 15, 2025 12:10:54 AM
> Subject: Re: My experience using Java to do CLI Scripting

> On 4/14/25 1:48 PM, Remi Forax wrote:
>>> From: "Ron Pressler" 
>>> This does what you want (and could even be combined to a single expression):
>>>
>>>     Process p = new ProcessBuilder("ls", "-al").start();
>>>     String result = p.inputReader().lines().collect(Collectors.joining("\n"));
>>>
>>> and it?s even nicer in the cases where you may want to process the output line
>>> by line, as many scripts do.
>> 
>> Hi Ron,
>> i think you need to close the inputReader
> 
> A few points here...
> 
> It might be possible to get away without any Process-related cleanup. For one,
> there's no "close" method on Process or ProcessBuilder. The destroy() method
> will
> certainly clean up, but you don't want that; and waitFor() merely waits for
> termination but doesn't actually clean anything up.
> 
> At least in the Unix ProcessImpl class, there's a bunch of infrastructure to
> handle
> exit of the underlying process, drain input from its stdout/stderr, and close
> the
> pipes. (I didn't look on Windows.) So setting aside termination, IOException,
> and
> what to do with stderr, it seems possible to just get the inputReader() and do
> something with the characters it emits.

You mean by making the Process Closeable ?

> 
> Getting a stream of lines with lines() seems like a reasonable thing to do if
> you
> want to process the output line by line.

with the caveat that you have to close() the returned stream (like Files.lines()), something people will often forget.


> 
> There are other possibilities, taking a nod from Files, which has methods
> readAllLines() and readString(). Putting similar methods on some class in the
> Reader
> family might help considerably here. Or you could call Reader.transferTo(Writer)
> that will send the characters to any Writer that might have a useful
> destination.

+1 for readAllInputLines() and readInputString() on Process.

> 
> s'marks

regards,
R?mi


> 
> 
> 
> 
> 
>> 
>>    public static String output(String... args) {
>>      ProcessBuilder processBuilder = new ProcessBuilder(args);
>>      try {
>>        Process process = processBuilder.start();
>>        try (BufferedReader reader = process.inputReader()) {
>>          return reader.lines().collect(Collectors.joining("\n"));
>>        }
>>      } catch (IOException e) {
>>        throw new IOError(e);
>>      }
>>    }
>> 
>> 
>>>
>>> ? Ron
>>>
>> 
>> regards,
>> R?mi
>> 
>>>
>>>
>>>> On 14 Apr 2025, at 20:06, Cay Horstmann  wrote:
>>>>
>>>> Absolutely, ProcessBuilder/Process is the right approach.
>>>>
>>>> I realize that all those bells and whistles in the Process API are there for a
>>>> reason, but the API is a bit clunky for the happy day path that one usually has
>>>> in a script: running a process until it terminates and getting its output. It
>>>> is trivial to write a couple of helper methods, but it might be nice if the
>>>> Process API could help out. Something like
>>>>
>>>> Process p = Process.waitFor("ls", "-al");
>>>> String result = p.output();
>>>>
>>>> Cheers,
>>>>
>>>> Cay
>>>>
>>>> PS. This isn't pretty in Python either:
>>>> https://docs.python.org/3/library/subprocess.html#subprocess.run
>>>>
>>>>
>>>> Il 12/04/25 17:02, Ron Pressler ha scritto:
>>>>> Hi.
>>>>> Let?s focus on ProcessBuilder and Process (as I think that?s where you want to
>>>>> focus, and why I think this discussion is more appropriate for core-libs-dev).
>>>>> Can you try to show more concretely what the pain point is in your actual code?
>>>>> The ProcessBuilder example is long because it does multiple things, each of
>>>>> which may or may not be relevant to your use case. That doing five different
>>>>> things requires five lines of code doesn?t help us see where your specific pain
>>>>> point is.
>>>>> ? Ron
>>>>>> On 12 Apr 2025, at 15:39, David Alayachew  wrote:
>>>>>>
>>>>>> Hello Amber Dev Team and Kulla Dev Team,
>>>>>>
>>>>>> (I made a reddit post too, if you prefer to interact there instead --
>>>>>> https://www.reddit.com/r/java/comments/1jx87ys/)
>>>>>> The following JEP's have released recently.
>>>>>>      ? JEP 495: Simple Source Files and Instance Main Methods
>>>>>>      ? JEP 330: Launch Single-File Source-Code Programs
>>>>>>      ? JEP 222: jshell: The Java Shell (Read-Eval-Print Loop)
>>>>>> These have made it really easy for me to do CLI scripting in Java, as opposed to
>>>>>> Bash. However, I've run into some pain points, as I've relied more and more on
>>>>>> Java.
>>>>>> For starters, the hand off from Java --> Bash is kind of ugly. Bash --> Java is
>>>>>> not bad, due to void main(final String[] args), as well as Bash's xargs. But
>>>>>> Java --> Bash is ugly, and here is an example demonstrating how/why.
>>>>>> I use AWS CLI to manage my dev environment. It's super powerful, and is all
>>>>>> available directly from the CLI, using simple Bash or even CMD.
>>>>>> Let's say I use AWS CLI to gather some ad-hoc information about my entire dev
>>>>>> environment. How do I manage the multiple handoffs back and forth between AWS
>>>>>> CLI and Java?
>>>>>> There are no good answers.
>>>>>>      ? Store the results into a file, then use JShell/java(c) to process the output
>>>>>>      file from Bash/AWS CLI.
>>>>>>          ? There's multiple handoffs back and forth between AWS CLI and Java. So, every
>>>>>>          handoff from Java ---> AWS CLI means generating a new file, thus increasing the
>>>>>>          complexity and cruft. It's unideal.
>>>>>>      ? Use Java's ProcessBuilder and Process classes.
>>>>>>          ? This works, but is heavy-handed. Look at the examples in those links. That is
>>>>>>          multiple lines of code to represent a single bash command. It does appear to be
>>>>>>          the idiomatic way, though.
>>>>>>      ? Do all upstream processing with AWS CLI in Bash directly, then do only a
>>>>>>      single handoff to Java, once I have done all I need to with AWS CLI.
>>>>>>          ? This is definitely the least painful, but it also means I don't use much Java
>>>>>>          at all. And any changes in upstream processing must be done in Bash to avoid
>>>>>>          handoff headaches from AWS CLI ---> Java.
>>>>>>      ? Download the AWS SDK Jar files and just do it all in Java.
>>>>>>          ? Ignoring the fact that some things are much harder to do via the AWS Java
>>>>>>          SDK's, there's actually some functionality that just isn't available via the
>>>>>>          Java ones. I'd have to recreate it myself, and it would be a significant lift.
>>>>>> Option 4 is best when I am building an application, but for ad-hoc checks that I
>>>>>> want to do on the fly (my most common use-case by far), I have been using
>>>>>> Option 3.
>>>>>> I just wish I could use more Java. It's a FAR BETTERtool than Bash, but I can't
>>>>>> justify the level of effort for ad-hoc use cases because of the poor hand off
>>>>>> from Java --> Bash. And since AWS CLI is only available via Bash/CMD, I'm stuck
>>>>>> with a bunch of not-good choices.
>>>>>> CLI Scripting in Java is great, but I wanted to highlight this pain point to
>>>>>> spread awareness.
>>>>>> Can you relate?
>>>>>>
>>>>
>>>> --
>>>>
> >>> Cay S. Horstmann | https://horstmann.com

From ron.pressler at oracle.com  Tue Apr 15 10:04:32 2025
From: ron.pressler at oracle.com (Ron Pressler)
Date: Tue, 15 Apr 2025 10:04:32 +0000
Subject: [External] : Re: My experience using Java to do CLI Scripting
In-Reply-To: 
References: 
 <356624F4-6FE4-4D22-92EE-049C1E03472C@oracle.com>
 <0be34f61-8b4b-494d-bb4a-2d21fb3127e7@gmail.com>
 <1E97A470-8441-4DF6-B266-CE45956075F2@oracle.com>
 <778403719.226536541.1744663720524.JavaMail.zimbra@univ-eiffel.fr>
 
 
Message-ID: <31774313-B720-4DFC-BC08-4C9B0645DC7B@oracle.com>



> On 15 Apr 2025, at 07:52, Cay Horstmann  wrote:
> 
> 
> 
> Il 14/04/25 23:46, Ron Pressler ha scritto:
>>> On 14 Apr 2025, at 21:48, Remi Forax  wrote:
>>> 
>>> 
>>> Hi Ron,
>>> i think you need to close the inputReader
>>> 
>>>  public static String output(String... args) {
>>>    ProcessBuilder processBuilder = new ProcessBuilder(args);
>>>    try {
>>>      Process process = processBuilder.start();
>>>      try (BufferedReader reader = process.inputReader()) {
>>>        return reader.lines().collect(Collectors.joining("\n"));
>>>      }
>>>    } catch (IOException e) {
>>>      throw new IOError(e);
>>>    }
>>>  }
>> When the process terminates, the InputStream underlying the pipe is closed (after being drained and the unread bytes served by a ByteArrayInputStream), which *I think* should be sufficient, but I could be wrong.
>> ? Ron
> 
> Reading the process output into a string or string stream raises a number of worries.
> 
> * Do I need to wait for the process to complete?

I don?t know all the error conditions, but since you?re reading the stream until its end, and this pipe ends when the process closes, then I don?t think you need to also wait for the process complete, but you may want to call waitFor to get the exit status.

> * Do I need to close anything?

It seems to me that all the pipes are closed when the process ends, so no, but I?m not an expert in this area. 

> * How exactly do I use getInputStream()/inputReader() with *extreme care*, as the API doc warns me?

I think that note cautions that if you want to use that pair of methods *together*, then be careful because they?re both reading from the same underlying stream.

> 
> If it is safe to call
> 
>  builder.start().inputReader().lines()
> 
> or
> 
>  builder.start().getInputStream().readAllBytes()
> 
> without waiting or closing, then the API doc could say so.

I think so, and so I guess the doc should say that, but there could be error conditions that complicate matters (e.g. what happens if your thread is interrupted?)

> If not, then maybe a safe method to get the entire output would be appropriate for Process?
> 

In what form, though? A Stream of lines seems the most flexible and convenient ? calling .toList() on it seems especially convenient.

But perhaps that hypothetical Process.inputLines() method could also have the returned Stream throw an exception if the process terminates with a non-zero code, making things even more convenient, like so:

    var p = new ProcessBuilder("ls", "-al").start();
    try {
        var lines = p.inputLines().toList();
        ...
    } catch (ProcessFailedException ex) {
        var errorLines = p.errorLines().toList();
        ...
    }

? Ron



From sgehwolf at openjdk.org  Tue Apr 15 10:19:55 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 15 Apr 2025 10:19:55 GMT
Subject: Integrated: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493
In-Reply-To: 
References: 
Message-ID: 

On Wed, 2 Apr 2025 18:39:57 GMT, Severin Gehwolf  wrote:

> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
> 
> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
> 
> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
> 2. For those files the hash sum checks are skipped.
> 
> **Testing**
> 
> - [x] GHA
> - [x] `jdk/tools/jlink` jtreg tests (also on [GHA](https://github.com/jerboaa/jdk/actions/runs/14376644254))
> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
> 
> Thoughts?

This pull request has now been integrated.

Changeset: 4e24dc00
Author:    Severin Gehwolf 
URL:       https://git.openjdk.org/jdk/commit/4e24dc003c2304041b342371adf430b120a9fec8
Stats:     254 lines in 5 files changed: 250 ins; 0 del; 4 mod

8353185: Introduce the concept of upgradeable files in context of JEP 493

Reviewed-by: clanger, ihse, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/24388

From michaelm at openjdk.org  Tue Apr 15 11:10:49 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 15 Apr 2025 11:10:49 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v5]
In-Reply-To: 
References: 
 
 
Message-ID: <4T-aEuL5RC4ragkopv7afbUBA3NT9efLxcG6EZGCJ8o=.65b066df-bc22-4df5-a7b8-c09b8e7515f7@github.com>

On Mon, 14 Apr 2025 13:51:30 GMT, Daniel Fuchs  wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update to minimise code changes
>
> src/java.base/share/classes/java/net/Proxy.java line 102:
> 
>> 100:                 formatMsg("type " + type + " is not compatible with address %s",
>> 101:                           filterNetInfo(sa.toString())
>> 102:                                .replaceWith("type " + sa.getClass().toString())));
> 
> You will have to guard against sa == null here

The `replaceWith()` call is actually not needed at all. I will remove it

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2044273655

From michaelm at openjdk.org  Tue Apr 15 11:24:47 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 15 Apr 2025 11:24:47 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v5]
In-Reply-To: 
References: 
 
 
Message-ID: <5ovW0BNN592wq1AFeHxH0QsrKk-hDXqCtGHgwRJ6StU=.ab9fa83f-27a7-485f-b586-4b1572329694@github.com>

On Mon, 14 Apr 2025 14:20:39 GMT, Daniel Fuchs  wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update to minimise code changes
>
> test/jdk/java/net/URI/Test.java line 29:
> 
>> 27:  *      7171415 6339649 6933879 8037396 8272072 8051627 8297687
>> 28:  * @author Mark Reinhold
>> 29:  * @run main/othervm -Djdk.includeInExceptions=hostInfo Test
> 
> This change does not look like it's needed.

Thanks for the review.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2044297016

From tpushkin at openjdk.org  Tue Apr 15 11:25:43 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 15 Apr 2025 11:25:43 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v6]
In-Reply-To: 
References: 
 
 
 <-r-008S-HtyyMBystnDKZZUaiCGdbUHSx7v87MeWatA=.02df1f9f-a85e-4136-a1a7-672782415527@github.com>
 
Message-ID: 

On Tue, 15 Apr 2025 00:58:19 GMT, Ioi Lam  wrote:

>> This case will work, I've added the test, however I found another case which won't be handled correctly, neither before nor after this change.
>> 
>> This is the case you've suggested, it works fine both before and after the change.
>> 
>> java/lang/Object id: 0
>> CustomLoadee3 id: 1
>> CustomLoadee3 id: 2 super: 0 source: a.jar
>> CustomLoadee3Child id: 3 super: 2 source: a.jar
>> 
>> 
>> However the below one doesn't work neither before nor after this change. At dump time, 2 is loaded instead of 1 as the super of 3 because 2, 3 are loaded by the same class loader and 1, 2 have the same name. It is possible to get such class list if 2 is loaded by a non-delegating unregistered loader while 3 is loaded by a different delegating one.
>> 
>> # Difference with the previous: super of the last class
>> java/lang/Object id: 0
>> CustomLoadee3 id: 1
>> CustomLoadee3 id: 2 super: 0 source: a.jar
>> CustomLoadee3Child id: 3 super: 1 source: a.jar
>> 
>> 
>> And the following case is working without this change but will not work with it. It is working now because there will be two different unregistered loaders for classes 2 and 3 (because they have the same source), however with this change there will be one and it will re-use 2 already loaded by it when loading 3.
>> 
>> # Difference with the previous: source of the last class
>> java/lang/Object id: 0
>> CustomLoadee3 id: 1
>> CustomLoadee3 id: 2 super: 0 source: a.jar
>> CustomLoadee3Child id: 3 super: 1 source: b.jar
>> 
>> 
>> Although the last case is a regression, I am not sure how much of a problem this is since in general having a registered super with the same name as another unregistered class is not supported anyway as shown by the second case.
>
> Thanks for doing the investigation. I think we are always going to have some corner cases that cannot be covered:
> 
> - For your second case, we would need a separate ClassLoader per class.
> - However, that will result in the IllegalAccessError in the current PR
> 
> The problem is we are trying to reconstruct the classes without reconstructing the ClassLoaders. A real solution would probably require updating the classlist format.
> 
> However, future CDS improvements will be based on the AOT cache introduced in JEP 483. As of JDK 25, we have changed the AOT cache configuration file from a text file (classlist) to a binary file (see https://github.com/openjdk/jdk/pull/23484) . Also, the unregistered classes are saved from the training run, where we still have ClassLoader information (see https://github.com/openjdk/jdk/pull/23926). Therefore, I think we should just leave the old classlist format as is, and accept that certain unregistered classes cannot be supported. I'll try add some test cases ([JDK-8354557](https://bugs.openjdk.org/browse/JDK-8354557)) for the AOT cache using the test cases you identified above.
> 
> This PR address the IllegalAccessError problem and simplifies the implementation of classlist handling. However, it causes incompatibility (in your third case). I think we should change the error checking code in `InstanceKlass* ClassListParser::load_class_from_source()` to print a warning message and continue. These are the rare cases that we cannot support. Since CDS is just a cache mechanism, it should be acceptable that certain classes are not supported. We can use your second and third test cases to validate the warning messages.

I fully agree, will implement the warnings

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2044299087

From ron.pressler at oracle.com  Tue Apr 15 12:30:47 2025
From: ron.pressler at oracle.com (Ron Pressler)
Date: Tue, 15 Apr 2025 12:30:47 +0000
Subject: [External] : Re: My experience using Java to do CLI Scripting
In-Reply-To: <1168340462.227175047.1744710667933.JavaMail.zimbra@univ-eiffel.fr>
References: 
 <356624F4-6FE4-4D22-92EE-049C1E03472C@oracle.com>
 <0be34f61-8b4b-494d-bb4a-2d21fb3127e7@gmail.com>
 <1E97A470-8441-4DF6-B266-CE45956075F2@oracle.com>
 <778403719.226536541.1744663720524.JavaMail.zimbra@univ-eiffel.fr>
 <2caec135-cdb2-46d4-b46d-e6979f99b6ae@oracle.com>
 <1168340462.227175047.1744710667933.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <4570585B-0BFA-49DC-BA5F-4DE04110A6C0@oracle.com>



> On 15 Apr 2025, at 10:51, forax at univ-mlv.fr wrote:
> 
> ----- Original Message -----
>> From: "Stuart Marks" 
>> To: "Remi Forax" , "Ron Pressler" , "David Alayachew"
>> 
>> Cc: "cay horstmann" , "core-libs-dev" 
>> Sent: Tuesday, April 15, 2025 12:10:54 AM
>> Subject: Re: My experience using Java to do CLI Scripting
>> 
>> A few points here...
>> 
>> It might be possible to get away without any Process-related cleanup. For one,
>> there's no "close" method on Process or ProcessBuilder. The destroy() method
>> will
>> certainly clean up, but you don't want that; and waitFor() merely waits for
>> termination but doesn't actually clean anything up.
>> 
>> At least in the Unix ProcessImpl class, there's a bunch of infrastructure to
>> handle
>> exit of the underlying process, drain input from its stdout/stderr, and close
>> the
>> pipes. (I didn't look on Windows.) So setting aside termination, IOException,
>> and
>> what to do with stderr, it seems possible to just get the inputReader() and do
>> something with the characters it emits.
> 
> You mean by making the Process Closeable ?

It could make sense to make Process AutoCloseable similar to how ExecutorService now works, i.e. by having the close method call waitFor.

> 
>> 
>> Getting a stream of lines with lines() seems like a reasonable thing to do if
>> you
>> want to process the output line by line.
> 
> with the caveat that you have to close() the returned stream (like Files.lines()), something people will often forget.
> 

The three Process streams are created (by default) whether you ever use them or not, so if you did have to close them, you?d need to do it every time you use Process. The reason is that the IO scaffolding (including ensuring cleanup) needs to be set up as soon as the process is started, before we know if you?re interested in reading the output. I think that if you want the streams to *not* be opened, you need to ask ProcessBuilder explicitly with ProcessBuilder.Redirect.DISCARD.

It seems to me that on Unix, the pipes are all closed as soon as the process terminates. On Windows it?s more complicated and there may be Cleaners involved (and the buffering done by the OS rather than Java?), but on either platform it seems that it doesn?t matter whether you actually use the streams. 

Perhaps Roger can clarify, or correct me if I?m wrong.

> 
>> 
>> There are other possibilities, taking a nod from Files, which has methods
>> readAllLines() and readString(). Putting similar methods on some class in the
>> Reader
>> family might help considerably here. Or you could call Reader.transferTo(Writer)
>> that will send the characters to any Writer that might have a useful
>> destination.
> 
> +1 for readAllInputLines() and readInputString() on Process.

Wouldn?t it make more sense to add these to BufferedReader?

? Ron



From alanb at openjdk.org  Tue Apr 15 13:05:45 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Apr 2025 13:05:45 GMT
Subject: RFR: 8354450: Using a File with a path containing a trailing space
 should fail when alternative data streams are disabled (win)
In-Reply-To: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
References: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
Message-ID: 

On Mon, 14 Apr 2025 20:57:17 GMT, Brian Burkhalter  wrote:

> In `java.io.WinNTFileSystem::isInvalid`, replace an insufficient test for file path validity with a sufficient test for file path invalidity. Also, add a new test.

I don't think we can't couple these too, meaning the ADS configuration shouldn't influence whether trailing spaces are allowed. I think we can still fat path when the input doesn't contain a space, just might need a slower path when the input has a space.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24635#issuecomment-2804985095

From sgehwolf at openjdk.org  Tue Apr 15 13:15:01 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 15 Apr 2025 13:15:01 GMT
Subject: RFR: 8354629: Test tools/jlink/ClassFileInMetaInfo.java fails on
 builds with configure option --enable-linkable-runtime
Message-ID: 

Please review this trivial test-only fix. A new test introduced with [JDK-8353267](https://bugs.openjdk.org/browse/JDK-8353267) runs `jlink` using the `ToolProvider` API in-process. This is problematic for JEP 493 enabled builds which don't allow to be run on a patched JDK. Note that JTREG patches the JDK's `java.base` module with `JTRegModuleHelper` class. The fix is to run in `othervm` instead.

Testing:
- [ ] GHA
- [x] jlink tests on a build with `--enable-linkable-runtime`. Shows the failure before and passes after.

Thoughts?

-------------

Commit messages:
 - 8354629: Test tools/jlink/ClassFileInMetaInfo.java fails on builds with configure option --enable-linkable-runtime

Changes: https://git.openjdk.org/jdk/pull/24661/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24661&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354629
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24661.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24661/head:pull/24661

PR: https://git.openjdk.org/jdk/pull/24661

From vklang at openjdk.org  Tue Apr 15 13:17:48 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 15 Apr 2025 13:17:48 GMT
Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth
 Preview) [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 7 Nov 2024 10:51:15 GMT, Alan Bateman  wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - Add JEP number, update copyright headers
>>  - Merge branch 'master' into JDK-8342486
>>  - Sync up from loom repo
>>  - Merge branch 'master' into JDK-8342486
>>  - Sync up from loom repo
>>  - Merge branch 'master' into JDK-8342486
>>  - Merge branch 'master' into JDK-8342486
>>  - Fix link
>>  - Merge branch 'master' into JDK-8342486
>>  - Sync up impl/tests form loom repo
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/3090e218...418bc3d3
>
> src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 337:
> 
>> 335:  * 
>> 336:  * happen-before any actions taken by that subtask, which in turn
>> 337:  * happen-before the subtask result is {@linkplain Subtask#get() retrieved}.
> 
> Chen has suggested that this be expanded to specify a HB between onComplete and join. Viktor and I have discussed extending the existing text to deal with subtask outcome that "contributes" to the scope result but did not agree wording (note that this is a pre-existing short-coming in the spec, not a new issue).

I'm not sure where we are on this topic. Clearly there's an edge between the pre-join and post-join phases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2044516724

From alanb at openjdk.org  Tue Apr 15 13:39:44 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Apr 2025 13:39:44 GMT
Subject: RFR: 8354629: Test tools/jlink/ClassFileInMetaInfo.java fails on
 builds with configure option --enable-linkable-runtime
In-Reply-To: 
References: 
Message-ID: 

On Tue, 15 Apr 2025 13:09:31 GMT, Severin Gehwolf  wrote:

> Please review this trivial test-only fix. A new test introduced with [JDK-8353267](https://bugs.openjdk.org/browse/JDK-8353267) runs `jlink` using the `ToolProvider` API in-process. This is problematic for JEP 493 enabled builds which don't allow to be run on a patched JDK. Note that JTREG patches the JDK's `java.base` module with `JTRegModuleHelper` class. The fix is to run in `othervm` instead.
> 
> Testing:
> - [ ] GHA
> - [x] jlink tests on a build with `--enable-linkable-runtime`. Shows the failure before and passes after.
> 
> Thoughts?

okay

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24661#pullrequestreview-2768311359

From alanb at openjdk.org  Tue Apr 15 13:40:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Apr 2025 13:40:49 GMT
Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth
 Preview) [v8]
In-Reply-To: 
References: 
 
 
Message-ID: <8KX_1xd1YhpEav0iSk_wvDEwnEJaEqwVl3KqgIN8p8c=.9813cb42-ab89-43c2-b0fb-f0b5d9955702@github.com>

On Tue, 15 Apr 2025 13:15:25 GMT, Viktor Klang  wrote:

>> src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 337:
>> 
>>> 335:  * 
>>> 336:  * happen-before any actions taken by that subtask, which in turn
>>> 337:  * happen-before the subtask result is {@linkplain Subtask#get() retrieved}.
>> 
>> Chen has suggested that this be expanded to specify a HB between onComplete and join. Viktor and I have discussed extending the existing text to deal with subtask outcome that "contributes" to the scope result but did not agree wording (note that this is a pre-existing short-coming in the spec, not a new issue).
>
> I'm not sure where we are on this topic. Clearly there's an edge between the pre-join and post-join phases.

Yes, but it would be a topic for a different PR as we haven't changed anything here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2044567696

From duke at openjdk.org  Tue Apr 15 14:15:15 2025
From: duke at openjdk.org (Johannes Graham)
Date: Tue, 15 Apr 2025 14:15:15 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when used
 concurrently
Message-ID: 

The `DigitList` class used in `DecimalFormat` does not reset the `data` array in its clone method. This can cause interference when clones are used concurrently.

-------------

Commit messages:
 - reset "data" field in clone

Changes: https://git.openjdk.org/jdk/pull/24598/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24598&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354522
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24598.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24598/head:pull/24598

PR: https://git.openjdk.org/jdk/pull/24598

From duke at openjdk.org  Tue Apr 15 14:15:15 2025
From: duke at openjdk.org (Johannes Graham)
Date: Tue, 15 Apr 2025 14:15:15 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently
In-Reply-To: 
References: 
Message-ID: <1OuT0uIz1V0Zg_Z8xlhuZ1xXl9jKZZppk2sZeXuFgGs=.caf7fcce-96a4-4818-b714-9d8a9ef04389@github.com>

On Fri, 11 Apr 2025 17:31:08 GMT, Johannes Graham  wrote:

> The `DigitList` class used in `DecimalFormat` does not reset the `data` array in its clone method. This can cause interference when clones are used concurrently.

Reproducing code example:


public class DecimalFormatTest {
    static AtomicInteger mismatchCount = new AtomicInteger(0);

    public static void main(String[] args) {
        DecimalFormat df = new DecimalFormat("#");
        String str = df.format(Math.PI); // initial use of formatter
        System.out.println(str);

        try (var ex = Executors.newThreadPerTaskExecutor(Thread.ofPlatform().factory())) {
            for (int i = 0; i < 50; i++) {
                // each thread gets its own clone of df
                DecimalFormat threadDf = (DecimalFormat) df.clone();
                ex.execute(makeTask(threadDf));
            }
        }

        System.out.println("mismatchCount = " + mismatchCount);
    }

    private static Runnable makeTask(DecimalFormat threadDf) {
        return () -> {
            for (int i = 0; i < 1000000; i++) {
                String dfString = threadDf.format(BigDecimal.valueOf(i));
                String str = String.valueOf(i);
                if (!str.equals(dfString)) {
                    System.err.println("mismatch: str = " + str + " dfString = " + dfString);
                    mismatchCount.incrementAndGet();
                }
            }
        };
    }
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24598#issuecomment-2797607528

From alanb at openjdk.org  Tue Apr 15 14:22:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Apr 2025 14:22:59 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Apr 2025 17:31:08 GMT, Johannes Graham  wrote:

> The `DigitList` class used in `DecimalFormat` does not reset the `data` array in its clone method. This can cause interference when clones are used concurrently.

Are you going to turn the reproducer into a test? I don't know if we have tests that for DecimalFormat cloning.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24598#issuecomment-2805363472

From michaelm at openjdk.org  Tue Apr 15 14:35:28 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 15 Apr 2025 14:35:28 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v6]
In-Reply-To: 
References: 
Message-ID: <_RtwTSEJW4kr0WOiLRIp3oc8CbpaMjIe2u5xjfYJIH0=.87e0cd7f-7e46-4b2c-9b30-60a7758f1ee2@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - review update
 - Merge branch 'master' into 8348986-exceptions
 - update to minimise code changes
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Apply suggestions from code review
   
   from turbanoff review
   
   Co-authored-by: Andrey Turbanov 
 - doc + copyright update
 - remove file added by mistake
 - whitespace
 - moved test
 - ... and 10 more: https://git.openjdk.org/jdk/compare/b7837843...da33863c

-------------

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=05
  Stats: 948 lines in 42 files changed: 715 ins; 101 del; 132 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From duke at openjdk.org  Tue Apr 15 14:43:56 2025
From: duke at openjdk.org (Johannes Graham)
Date: Tue, 15 Apr 2025 14:43:56 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v2]
In-Reply-To: 
References: 
Message-ID: 

> The `DigitList` class used in `DecimalFormat` does not reset the `data` array in its clone method. This can cause interference when clones are used concurrently.

Johannes Graham has updated the pull request incrementally with two additional commits since the last revision:

 - fix test summary
 - add test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24598/files
  - new: https://git.openjdk.org/jdk/pull/24598/files/7ef4cb62..880b2d89

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24598&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24598&range=00-01

  Stats: 69 lines in 1 file changed: 69 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24598.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24598/head:pull/24598

PR: https://git.openjdk.org/jdk/pull/24598

From duke at openjdk.org  Tue Apr 15 14:58:40 2025
From: duke at openjdk.org (Johannes Graham)
Date: Tue, 15 Apr 2025 14:58:40 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v2]
In-Reply-To: 
References: 
 
Message-ID: <5psauskNHRzKe3jxZfz8acQySY8igmWV_HgLdnK1SMU=.e128ce06-3f7f-425f-a6e3-206fce59e87a@github.com>

On Tue, 15 Apr 2025 14:43:56 GMT, Johannes Graham  wrote:

>> The `DigitList` class used in `DecimalFormat` does not reset the `data` array in its clone method. This can cause interference when clones are used concurrently.
>
> Johannes Graham has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix test summary
>  - add test

I didn't notice any existing tests - I've added  a version of the reproducer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24598#issuecomment-2805786838

From dfuchs at openjdk.org  Tue Apr 15 15:08:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Apr 2025 15:08:57 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v6]
In-Reply-To: <_RtwTSEJW4kr0WOiLRIp3oc8CbpaMjIe2u5xjfYJIH0=.87e0cd7f-7e46-4b2c-9b30-60a7758f1ee2@github.com>
References: 
 <_RtwTSEJW4kr0WOiLRIp3oc8CbpaMjIe2u5xjfYJIH0=.87e0cd7f-7e46-4b2c-9b30-60a7758f1ee2@github.com>
Message-ID: 

On Tue, 15 Apr 2025 14:35:28 GMT, Michael McMahon  wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - update to minimise code changes
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Apply suggestions from code review
>    
>    from turbanoff review
>    
>    Co-authored-by: Andrey Turbanov 
>  - doc + copyright update
>  - remove file added by mistake
>  - whitespace
>  - moved test
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/b7837843...da33863c

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23929#pullrequestreview-2768796475

From liach at openjdk.org  Tue Apr 15 15:19:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Apr 2025 15:19:49 GMT
Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth
 Preview) [v8]
In-Reply-To: 
References: 
 
Message-ID: <4avbKRYklQvJdOqJoQZyMopzZ0GmZx9MYXS-dl2gPEE=.6297c48a-42f6-4106-8456-bffec459f672@github.com>

On Tue, 15 Apr 2025 06:36:20 GMT, Alan Bateman  wrote:

>> Changes for [JEP 505: Structured Concurrency (Fifth Preview)](https://openjdk.org/jeps/8340343). The proposal is to re-preview the API with some changes, specifically:
>> 
>> - A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor.  Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close.
>> - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner.
>> - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions.
>> - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function.
>> - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method.
>>  
>> The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Add JEP number, update copyright headers
>  - Merge branch 'master' into JDK-8342486
>  - Sync up from loom repo
>  - Merge branch 'master' into JDK-8342486
>  - Sync up from loom repo
>  - Merge branch 'master' into JDK-8342486
>  - Merge branch 'master' into JDK-8342486
>  - Fix link
>  - Merge branch 'master' into JDK-8342486
>  - Sync up impl/tests form loom repo
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/3090e218...418bc3d3

src/java.base/share/classes/java/util/concurrent/Joiners.java line 93:

> 91:             return (state == Subtask.State.FAILED)
> 92:                     && (firstException == null)
> 93:                     && FIRST_EXCEPTION.compareAndSet(this, null, subtask.exception());

1. Should we add the other exceptions as suppressed to the first?
2. If we have stable values, we can use a stable value to racily set the first exception.

src/java.base/share/classes/java/util/concurrent/Joiners.java line 190:

> 188:      * A joiner that returns a stream of all subtasks.
> 189:      */
> 190:     static class AllSubtasks implements Joiner>> {

Suggestion:

    static final class AllSubtasks implements Joiner>> {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2043738283
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2043741615

From bpb at openjdk.org  Tue Apr 15 15:24:41 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Apr 2025 15:24:41 GMT
Subject: RFR: 8354450: Using a File with a path containing a trailing space
 should fail when alternative data streams are disabled (win)
In-Reply-To: 
References: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
 
Message-ID: 

On Tue, 15 Apr 2025 13:03:03 GMT, Alan Bateman  wrote:

> I don't think we should couple these two, meaning the ADS configuration shouldn't influence whether trailing spaces are allowed. I think we can still fat path when the input doesn't contain a space, just might need a slower path when the input has a space.

Agreed. I was thinking that lines 371-377 should come before line 368 and possibly also check for a trailing space.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24635#issuecomment-2806162661

From alanb at openjdk.org  Tue Apr 15 15:43:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Apr 2025 15:43:51 GMT
Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth
 Preview) [v8]
In-Reply-To: <4avbKRYklQvJdOqJoQZyMopzZ0GmZx9MYXS-dl2gPEE=.6297c48a-42f6-4106-8456-bffec459f672@github.com>
References: 
 
 <4avbKRYklQvJdOqJoQZyMopzZ0GmZx9MYXS-dl2gPEE=.6297c48a-42f6-4106-8456-bffec459f672@github.com>
Message-ID: 

On Tue, 15 Apr 2025 06:35:53 GMT, Chen Liang  wrote:

> 1. Should we add the other exceptions as suppressed to the first?

It's a good question and one that we mulled over when creating STS.ShutdownOnFailure. We're not proposing to change it in this update as it doesn't scale when many subtasks fail around the same time, is confusing to see many suppressed exceptions from different subtasks, and incomplete when subtasks fail after the scope is cancelled. For logging/other needs here then it would be simpler to just use a different joiner that returns all subtasks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2044938865

From asemenyuk at openjdk.org  Tue Apr 15 16:09:02 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 15 Apr 2025 16:09:02 GMT
Subject: Integrated: 8354320: Changes to jpackage.md cause pandoc warning
In-Reply-To: 
References: 
Message-ID: <7dFq6vZtbr_Pi7SEFSPm7GWxJiZ_MATP9FWa4XXUrfQ=.4608369f-a007-4f67-b677-d51e78cc3ab9@github.com>

On Thu, 10 Apr 2025 21:50:10 GMT, Alexey Semenyuk  wrote:

> Escape the dollar sign.

This pull request has now been integrated.

Changeset: fc146472
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/fc1464727f95508935cfc65d689b74e1709d3649
Stats:     10 lines in 2 files changed: 8 ins; 0 del; 2 mod

8354320: Changes to jpackage.md cause pandoc warning

Reviewed-by: almatvee, ihse, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/24585

From naoto at openjdk.org  Tue Apr 15 16:22:47 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 15 Apr 2025 16:22:47 GMT
Subject: RFR: 8354084: Streamline XPath API's extension function control
 [v3]
In-Reply-To: <0y0IinbBL-kjyu8eELDF1VqcJ_s7cChpMss0MNuua2w=.5640dfbf-98c4-44e6-b9f4-053bf8a5fb84@github.com>
References: <2h00m7NTlmM0pu-x7bRU7_UfgKkS2WVJ4jUEF3hnkzo=.a48773d0-d6e6-4505-8511-76902957b9eb@github.com>
 <0y0IinbBL-kjyu8eELDF1VqcJ_s7cChpMss0MNuua2w=.5640dfbf-98c4-44e6-b9f4-053bf8a5fb84@github.com>
Message-ID: 

On Mon, 14 Apr 2025 21:00:22 GMT, Joe Wang  wrote:

>> Streamline the extension function control in the XPath API by relying solely on [XPathFunctionResolver](https://docs.oracle.com/en/java/javase/24/docs/api/java.xml/javax/xml/xpath/XPathFunctionResolver.html), which provides a secure and developer-defined mechanism. Remove the feature FEATURE_SECURE_PROCESSING and jdk.xml.enableExtensionFunctions from the decision path that are redundant with regard to XPath's Extension Functions.
>> 
>> Note the comment in JAXPExtensionsProvider, starting at  "JAXP 1.3 spec says When ...", was not accurate. Refer to the spec: https://docs.oracle.com/en/java/javase/24/docs/api/java.xml/javax/xml/XMLConstants.html#FEATURE_SECURE_PROCESSING, FSP does not have specific requirement for the XPath functions.
>> 
>> Tests:
>>     Tier1 - 3 passed with regard to this change. There were unrelated/known failures (e.g. bug8329757).
>>     JCK passed except the previously reported issue (JCK-7322355).
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rewind resource files, leave them to L10n resource files update

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24605#pullrequestreview-2769042262

From naoto at openjdk.org  Tue Apr 15 17:08:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 15 Apr 2025 17:08:56 GMT
Subject: RFR: 8354464: Additional cleanup setting up native.encoding
In-Reply-To: 
References: 
Message-ID: 

On Sat, 12 Apr 2025 02:19:35 GMT, Stuart Marks  wrote:

> Remove the #ifdef MACOSX from platform-independent System.c, which (on Mac) sets native.encoding from sprops.encoding or (on non-Mac Unix and Windows) sets native.encoding from sprops.sun_jnu_encoding. After this removal, the native.encoding property will be set from sprops.encoding and the sun.jnu.encoding property will be set from sprops.sun_jnu_encoding.
> 
> Change the windows java_props_md.c so that it initializes sprops.sun_jnu_encoding and then copies that value to sprops.encoding. Previously, sprops.encoding was initialized with data from other Windows APIs, but this value was ignored by platform-independent code, which was kind of confusing.
> 
> There are no changes to the Unix (Mac & non-Mac) platform-specific code. It already has code to set sprops.encoding and sprops.sun_jnu_encoding properly, including macOS-specific code to set the latter to UTF-8 unconditionally.
> 
> There should be no behavior changes on any platform.
> 
> I changed variable names in windows/java_props_md.c to make it clear that the values stored into them are unused. Of course there are other possibilities here, such as changing the interface to SetupI18nProps(). I'm open to suggestions.

Thanks for the clean-up, Stuart. Looks good to me.

src/java.base/share/native/libjava/System.c line 151:

> 149:     /* basic encoding properties, always non-NULL */
> 150:     PUTPROP(propArray, _native_encoding_NDX, sprops->encoding);
> 151:     PUTPROP(propArray, _sun_jnu_encoding_NDX, sprops->sun_jnu_encoding);

Since we now got rid of platform depenence here, would it make sense to perform non-null assertion in Java level here? I remember in the last PR we added `assert` in platform C code.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24607#pullrequestreview-2769173653
PR Review Comment: https://git.openjdk.org/jdk/pull/24607#discussion_r2045089359

From jlu at openjdk.org  Tue Apr 15 17:11:43 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 15 Apr 2025 17:11:43 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 15 Apr 2025 14:43:56 GMT, Johannes Graham  wrote:

>> The `DigitList` class used in `DecimalFormat` does not reset the `data` array in its clone method. This can cause interference when clones are used concurrently.
>
> Johannes Graham has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix test summary
>  - add test

Thanks for the fix, it looks good. Left some minor comments. I will run tiers 1-3 with your change.

src/java.base/share/classes/java/text/DigitList.java line 728:

> 726:             System.arraycopy(digits, 0, newDigits, 0, digits.length);
> 727:             other.digits = newDigits;
> 728:             other.data = null;

We don't have to copy the data _array_ unlike the _digits_ array (above) because it can just be reset during the next `getDataChars` call, but a comment as to why might be helpful.

test/jdk/java/text/Format/DecimalFormat/CloneTest.java line 27:

> 25:  * @test
> 26:  * @bug 8354522
> 27:  * @summary Check for cloning interference

It will probably be good to mention somewhere that this test/fix addresses the issue of the same _data_ array reference being shared amongst DigitList clones.

test/jdk/java/text/Format/DecimalFormat/CloneTest.java line 48:

> 46:         AtomicInteger mismatchCount = new AtomicInteger(0);
> 47:         DecimalFormat df = new DecimalFormat("#");
> 48:         String _ = df.format(Math.PI); // initial use of formatter

We should probably comment the importance of this line, as without it the test will pass without the fix. (It sets the _data_ array to a non null value).

test/jdk/java/text/Format/DecimalFormat/CloneTest.java line 54:

> 52:                 DecimalFormat threadDf = (DecimalFormat) df.clone();
> 53:                 Runnable task = () -> {
> 54:                     for (int j = 0; j < 1000000; j++) {

We should probably make this test less costly by decreasing some values, I don't the bug requires that many iterations to be exposed. (Without the fix and the `break` statement in the test, `mismatchCount` gets up into the tens of thousands on my machine.)

-------------

PR Review: https://git.openjdk.org/jdk/pull/24598#pullrequestreview-2769119077
PR Review Comment: https://git.openjdk.org/jdk/pull/24598#discussion_r2045055262
PR Review Comment: https://git.openjdk.org/jdk/pull/24598#discussion_r2045062899
PR Review Comment: https://git.openjdk.org/jdk/pull/24598#discussion_r2045083581
PR Review Comment: https://git.openjdk.org/jdk/pull/24598#discussion_r2045060617

From naoto at openjdk.org  Tue Apr 15 17:14:46 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 15 Apr 2025 17:14:46 GMT
Subject: RFR: 8354464: Additional cleanup setting up native.encoding
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 15 Apr 2025 17:04:35 GMT, Naoto Sato  wrote:

>> Remove the #ifdef MACOSX from platform-independent System.c, which (on Mac) sets native.encoding from sprops.encoding or (on non-Mac Unix and Windows) sets native.encoding from sprops.sun_jnu_encoding. After this removal, the native.encoding property will be set from sprops.encoding and the sun.jnu.encoding property will be set from sprops.sun_jnu_encoding.
>> 
>> Change the windows java_props_md.c so that it initializes sprops.sun_jnu_encoding and then copies that value to sprops.encoding. Previously, sprops.encoding was initialized with data from other Windows APIs, but this value was ignored by platform-independent code, which was kind of confusing.
>> 
>> There are no changes to the Unix (Mac & non-Mac) platform-specific code. It already has code to set sprops.encoding and sprops.sun_jnu_encoding properly, including macOS-specific code to set the latter to UTF-8 unconditionally.
>> 
>> There should be no behavior changes on any platform.
>> 
>> I changed variable names in windows/java_props_md.c to make it clear that the values stored into them are unused. Of course there are other possibilities here, such as changing the interface to SetupI18nProps(). I'm open to suggestions.
>
> src/java.base/share/native/libjava/System.c line 151:
> 
>> 149:     /* basic encoding properties, always non-NULL */
>> 150:     PUTPROP(propArray, _native_encoding_NDX, sprops->encoding);
>> 151:     PUTPROP(propArray, _sun_jnu_encoding_NDX, sprops->sun_jnu_encoding);
> 
> Since we now got rid of platform depenence here, would it make sense to perform non-null assertion in Java level here? I remember in the last PR we added `assert` in platform C code.

`Java level` -> `Platform independent C level`
Sorry

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24607#discussion_r2045102627

From vlivanov at openjdk.org  Tue Apr 15 17:46:46 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 15 Apr 2025 17:46:46 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 15 Apr 2025 09:29:32 GMT, Xiaohong Gong  wrote:

>> Vladimir Ivanov 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 19 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into vector.math.01.java
>>  - RVV and SVE adjustments
>>  - Merge branch 'master' into vector.math.01.java
>>  - Fix windows-aarch64 build failure
>>  - features_string -> cpu_info_string
>>  - Reviews and Float64Vector-related fix
>>  - Misc fixes and cleanups
>>  - CPU features support
>>  - Cleanup
>>  - TODO list
>>  - ... and 9 more: https://git.openjdk.org/jdk/compare/3a706abc...0ffed12f
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 198:
> 
>> 196:             if (vspecies.vectorBitSize() < 128) {
>> 197:                 return false; // 64-bit vectors are not supported
>> 198:             }
> 
> Thanks for your refactor. It's really a good job!  
> 
> It seems float type support 64-bit vector operations before (see https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp#L9835). Will this change the behavior of 64-bit float vector? Thanks!

Thanks for taking a look. 

In the latest version, Float64Vector cases should be properly handled.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2045156970

From ccheung at openjdk.org  Tue Apr 15 18:03:49 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 15 Apr 2025 18:03:49 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 14 Apr 2025 14:04:33 GMT, Timofei Pushkin  wrote:

>> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app.
>> 
>> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible.
>
> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused imports

I have one comment in CDS.java.

src/java.base/share/classes/jdk/internal/misc/CDS.java line 390:

> 388:             @Override
> 389:             public byte[] readClassFile(String className) throws IOException {
> 390:                 final var subPath = className.replace('.', File.separatorChar).concat(".class");

Should File.separatorChar be ?/? ? (just like at line 369)

-------------

PR Review: https://git.openjdk.org/jdk/pull/24223#pullrequestreview-2769319159
PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2045182045

From stuart.marks at oracle.com  Tue Apr 15 18:12:39 2025
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 15 Apr 2025 11:12:39 -0700
Subject: [External] : Re: My experience using Java to do CLI Scripting
In-Reply-To: 
References: 
 <356624F4-6FE4-4D22-92EE-049C1E03472C@oracle.com>
 <0be34f61-8b4b-494d-bb4a-2d21fb3127e7@gmail.com>
 <1E97A470-8441-4DF6-B266-CE45956075F2@oracle.com>
 <778403719.226536541.1744663720524.JavaMail.zimbra@univ-eiffel.fr>
 
 
Message-ID: 



On 4/14/25 11:52 PM, Cay Horstmann wrote:
> * How exactly do I use getInputStream()/inputReader() with *extreme care*, as the 
> API doc warns me?

Ah. This is referring to the following note in the Process.getInputStream() method spec:

> API Note:
>     Use getInputStream() and inputReader() with extreme care. The BufferedReader may have buffered input from the input stream.

The issue here is that the the inputReader is some Reader implementation (presumably 
a BufferedReader) wrapped around the same InputStream as returned by 
getInputStream(). If a program interleaves operations on the InputStream with 
operations on the Reader, it's unspecified which bytes will go where, and the 
results probably won't be useful.

(This is the same issue is wrapping System.in with a 
InputStreamReader/BufferedReader or with a Scanner, using them, and then going back 
to System.in to read more bytes.)

Even setting aside BufferedReader, any CharsetDecoder is allowed to buffer "extra" 
bytes from its input. Thus, mixing operations on a Reader and an underlying 
InputStream is inherently ill-defined. Essentially if you want to read bytes, use 
the InputStream, but if you want characters, use a Reader, and you can't mix them.

Anyway the wording here is quite vague and should be clarified. It should also be 
made normative, and a similar clause should be added to inputReader(). And maybe 
elsewhere.

**

There is a *separate* issue discussed elsewhere on this thread, which is what's 
necessary to make sure any resources associated with Process are cleaned up 
properly. We've observed that the Unix *implementation* cleans up pipes when the 
subprocess terminates... but this doesn't seem to be supported by the specs. So 
there's another set of issues to deal with, and possible enhancements to let 
applications perform cleanup more reliably.

s'marks


From stuart.marks at oracle.com  Tue Apr 15 18:29:11 2025
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 15 Apr 2025 11:29:11 -0700
Subject: [External] : Re: My experience using Java to do CLI Scripting
In-Reply-To: <4570585B-0BFA-49DC-BA5F-4DE04110A6C0@oracle.com>
References: 
 <356624F4-6FE4-4D22-92EE-049C1E03472C@oracle.com>
 <0be34f61-8b4b-494d-bb4a-2d21fb3127e7@gmail.com>
 <1E97A470-8441-4DF6-B266-CE45956075F2@oracle.com>
 <778403719.226536541.1744663720524.JavaMail.zimbra@univ-eiffel.fr>
 <2caec135-cdb2-46d4-b46d-e6979f99b6ae@oracle.com>
 <1168340462.227175047.1744710667933.JavaMail.zimbra@univ-eiffel.fr>
 <4570585B-0BFA-49DC-BA5F-4DE04110A6C0@oracle.com>
Message-ID: <4e950e87-3e65-4660-8734-647d90fbf95d@oracle.com>



On 4/15/25 5:30 AM, Ron Pressler wrote:
> On 15 Apr 2025, at 10:51, forax at univ-mlv.fr wrote:
 >> +1 for readAllInputLines() and readInputString() on Process.
> Wouldn?t it make more sense to add these to BufferedReader?

Yes. Process already has four Reader-based overloads:

  - inputReader()
  - inputReader(Charset)
  - errorReader()
  - errorReader(Charset)

We don't want to add all-lines and whole-string variations for each of these to 
Process, which would require eight new methods. There would need to be only two on 
BufferedReader, plus one could use them for reading text from other places (e.g., a 
socket).

s'marks


From duke at openjdk.org  Tue Apr 15 18:38:41 2025
From: duke at openjdk.org (Johannes Graham)
Date: Tue, 15 Apr 2025 18:38:41 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v3]
In-Reply-To: 
References: 
Message-ID: <05X4OYbR1-qoqS-1noYcV84uUKUTfs2qvisSJn0178U=.2858bc91-1c68-4096-bb1e-8311c41d02c4@github.com>

> The `DigitList` class used in `DecimalFormat` does not reset the `data` array in its clone method. This can cause interference when clones are used concurrently.

Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:

  Tune the test to shorten run-time, update comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24598/files
  - new: https://git.openjdk.org/jdk/pull/24598/files/880b2d89..61332647

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24598&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24598&range=01-02

  Stats: 34 lines in 2 files changed: 24 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/24598.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24598/head:pull/24598

PR: https://git.openjdk.org/jdk/pull/24598

From duke at openjdk.org  Tue Apr 15 18:38:45 2025
From: duke at openjdk.org (Johannes Graham)
Date: Tue, 15 Apr 2025 18:38:45 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <3XyFKa0rghCAAnA7J5A55kBsWqw2QzMsFglgfIvktYQ=.94ece871-65b4-4dde-904a-9cff9406b686@github.com>

On Tue, 15 Apr 2025 16:49:57 GMT, Justin Lu  wrote:

>> Johannes Graham has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix test summary
>>  - add test
>
> test/jdk/java/text/Format/DecimalFormat/CloneTest.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8354522
>> 27:  * @summary Check for cloning interference
> 
> It will probably be good to mention somewhere that this test/fix addresses the issue of the same _data_ array reference being shared amongst DigitList clones.

I added more detail to the comment with the test method.

> test/jdk/java/text/Format/DecimalFormat/CloneTest.java line 48:
> 
>> 46:         AtomicInteger mismatchCount = new AtomicInteger(0);
>> 47:         DecimalFormat df = new DecimalFormat("#");
>> 48:         String _ = df.format(Math.PI); // initial use of formatter
> 
> We should probably comment the importance of this line, as without it the test will pass without the fix. (It sets the _data_ array to a non null value).

Done

> test/jdk/java/text/Format/DecimalFormat/CloneTest.java line 54:
> 
>> 52:                 DecimalFormat threadDf = (DecimalFormat) df.clone();
>> 53:                 Runnable task = () -> {
>> 54:                     for (int j = 0; j < 1000000; j++) {
> 
> We should probably make this test less costly by decreasing some values, I don't the bug requires that many iterations to be exposed. (Without the fix and the `break` statement in the test, `mismatchCount` gets up into the tens of thousands on my machine.)

For the original reproducer I wanted to be _really_ sure that it failed. I've reduced it to be more reasonable. With the current config it still gets 10-100 mismatches for me. I've limited the number of lines that get logged as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24598#discussion_r2045232675
PR Review Comment: https://git.openjdk.org/jdk/pull/24598#discussion_r2045232933
PR Review Comment: https://git.openjdk.org/jdk/pull/24598#discussion_r2045235681

From naoto at openjdk.org  Tue Apr 15 19:20:40 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 15 Apr 2025 19:20:40 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v2]
In-Reply-To: <3XyFKa0rghCAAnA7J5A55kBsWqw2QzMsFglgfIvktYQ=.94ece871-65b4-4dde-904a-9cff9406b686@github.com>
References: 
 
 
 <3XyFKa0rghCAAnA7J5A55kBsWqw2QzMsFglgfIvktYQ=.94ece871-65b4-4dde-904a-9cff9406b686@github.com>
Message-ID: 

On Tue, 15 Apr 2025 18:35:17 GMT, Johannes Graham  wrote:

>> test/jdk/java/text/Format/DecimalFormat/CloneTest.java line 54:
>> 
>>> 52:                 DecimalFormat threadDf = (DecimalFormat) df.clone();
>>> 53:                 Runnable task = () -> {
>>> 54:                     for (int j = 0; j < 1000000; j++) {
>> 
>> We should probably make this test less costly by decreasing some values, I don't the bug requires that many iterations to be exposed. (Without the fix and the `break` statement in the test, `mismatchCount` gets up into the tens of thousands on my machine.)
>
> For the original reproducer I wanted to be _really_ sure that it failed. I've reduced it to be more reasonable. With the current config it still gets 10-100 mismatches for me. I've limited the number of lines that get logged as well.

If a mismatch is found, I think we can stop there and report error

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24598#discussion_r2045299428

From matsaave at openjdk.org  Tue Apr 15 19:53:50 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 15 Apr 2025 19:53:50 GMT
Subject: RFR: 8352001: AOT cache should not contain classes injected into
 built-in class loaders [v2]
In-Reply-To: <8E5mTxKlKyx63Zm9-O7pvcpCEQWuXuB_BPyeWqhY0u8=.91c08221-3f6b-4e08-996c-444602f3a456@github.com>
References: 
 <8E5mTxKlKyx63Zm9-O7pvcpCEQWuXuB_BPyeWqhY0u8=.91c08221-3f6b-4e08-996c-444602f3a456@github.com>
Message-ID: <_32DT-oOx-LzIjYCoG8l7nykQ6kpIOMYRJAJHviPnE8=.fbf64a54-cde8-4283-a11d-9036016458ab@github.com>

On Sat, 12 Apr 2025 18:37:18 GMT, Ioi Lam  wrote:

>> During an application's training run, it's possible to inject classes into the built-in platform/app class loaders with reflection calls. 
>> 
>> - Before [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), only the names of these classes were recorded in the AOT config file. When the AOT cache is generated, these classes are automatically filtered out.
>> - Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), these classes are stored as parsed InstanceKlasses in the AOT config file, and will be transferred into the AOT cache. This new behavior may cause some applications to fail, as they may inject bytecodes that have environment dependencies.
>> 
>> For safety, this PR filters out such injected classes from the AOT config file.
>
> Ioi Lam 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 'master' into 8352001-exclude-injected-classes-from-builtin-loaders
>  - 8352001: AOT cache should not contain classes injected into built-in class loaders

Looks good! Just one nit

src/hotspot/share/cds/aotClassLocation.cpp line 717:

> 715:                                                                           ik->name()->utf8_length());
> 716:       if (!zip->has_entry(current, file_name)) {
> 717:         log_warning(cds)("class %s cannot be archived because it was not define from %s as claimed",

Typo: define -> defined

test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/FakeCodeLocation.java line 122:

> 120:     // Define a class using Lookup.defineClass(). The ClassFileParser should see "__JVM_DefineClass__"
> 121:     // as the source location, so this class will be excluded, as the location is not supported.
> 122:     static void testWithLookup() throws Exception {

Should this test capture some kind of output or exception?

-------------

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24046#pullrequestreview-2769566562
PR Review Comment: https://git.openjdk.org/jdk/pull/24046#discussion_r2045329445
PR Review Comment: https://git.openjdk.org/jdk/pull/24046#discussion_r2045356365

From duke at openjdk.org  Tue Apr 15 20:09:58 2025
From: duke at openjdk.org (Johannes Graham)
Date: Tue, 15 Apr 2025 20:09:58 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v2]
In-Reply-To: 
References: 
 
 
 <3XyFKa0rghCAAnA7J5A55kBsWqw2QzMsFglgfIvktYQ=.94ece871-65b4-4dde-904a-9cff9406b686@github.com>
 
Message-ID: 

On Tue, 15 Apr 2025 19:18:03 GMT, Naoto Sato  wrote:

>> For the original reproducer I wanted to be _really_ sure that it failed. I've reduced it to be more reasonable. With the current config it still gets 10-100 mismatches for me. I've limited the number of lines that get logged as well.
>
> If a mismatch is found, I think we can stop there and report error

My thinking was that for a test pass, it would never hit the shortcut anyway, so it?s only an optimization for the failure case, which hopefully won?t happen anymore. Seeing the count of all collisions gives some reassurance that the test is still running for long enough to be effective.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24598#discussion_r2045393947

From naoto at openjdk.org  Tue Apr 15 20:24:59 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 15 Apr 2025 20:24:59 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v2]
In-Reply-To: 
References: 
 
 
 <3XyFKa0rghCAAnA7J5A55kBsWqw2QzMsFglgfIvktYQ=.94ece871-65b4-4dde-904a-9cff9406b686@github.com>
 
 
Message-ID: 

On Tue, 15 Apr 2025 20:07:09 GMT, Johannes Graham  wrote:

>> If a mismatch is found, I think we can stop there and report error
>
> My thinking was that for a test pass, it would never hit the shortcut anyway, so it?s only an optimization for the failure case, which hopefully won?t happen anymore. Seeing the count of all collisions gives some reassurance that the test is still running for long enough to be effective.

This is a regression test. Detecting the regression and keeping doing the same test is unnecessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24598#discussion_r2045414174

From duke at openjdk.org  Tue Apr 15 20:41:25 2025
From: duke at openjdk.org (Johannes Graham)
Date: Tue, 15 Apr 2025 20:41:25 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v4]
In-Reply-To: 
References: 
Message-ID: 

> The `DigitList` class used in `DecimalFormat` does not reset the `data` array in its clone method. This can cause interference when clones are used concurrently.

Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:

  Terminate test early on failure

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24598/files
  - new: https://git.openjdk.org/jdk/pull/24598/files/61332647..dc5e466e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24598&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24598&range=02-03

  Stats: 13 lines in 1 file changed: 5 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24598.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24598/head:pull/24598

PR: https://git.openjdk.org/jdk/pull/24598

From rriggs at openjdk.org  Tue Apr 15 20:49:51 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Apr 2025 20:49:51 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG  wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'

src/java.base/share/classes/java/lang/CharSequence.java line 338:

> 336:      * Concurrent truncation of this character sequence can throw
> 337:      * {@code IndexOutOfBoundsException}. In this case, some characters, but not
> 338:      * all, may be already transferred.

Though its been absent for decades, it might be worthwhile to include a class level warning that the implementations of the interface are not known or required to be thread safe and if used concurrently by multiple threads the behavior is unpredictable.  I'd be more circumspect than trying to specify the only aberrant behavior is IndexOutOfBounds.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2045454429

From duke at openjdk.org  Tue Apr 15 21:07:46 2025
From: duke at openjdk.org (Johannes Graham)
Date: Tue, 15 Apr 2025 21:07:46 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v2]
In-Reply-To: 
References: 
 
 
 <3XyFKa0rghCAAnA7J5A55kBsWqw2QzMsFglgfIvktYQ=.94ece871-65b4-4dde-904a-9cff9406b686@github.com>
 
 
 
Message-ID: 

On Tue, 15 Apr 2025 20:21:40 GMT, Naoto Sato  wrote:

>> My thinking was that for a test pass, it would never hit the shortcut anyway, so it?s only an optimization for the failure case, which hopefully won?t happen anymore. Seeing the count of all collisions gives some reassurance that the test is still running for long enough to be effective.
>
> This is a regression test. Detecting the regression and keeping doing the same test is unnecessary.

I?ve updated the test to exit early.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24598#discussion_r2045505613

From naoto at openjdk.org  Tue Apr 15 21:29:42 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 15 Apr 2025 21:29:42 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 15 Apr 2025 20:41:25 GMT, Johannes Graham  wrote:

>> The `DigitList` class used in `DecimalFormat` does not reset the `data` array in its clone method. This can cause interference when clones are used concurrently.
>
> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Terminate test early on failure

test/jdk/java/text/Format/DecimalFormat/CloneTest.java line 77:

> 75:                             String str = String.valueOf(value);
> 76:                             if (!str.equals(dfString)) {
> 77:                                 mismatchCount.getAndIncrement();

`mismatchCount` is no longer needed. Simply break after printing the error message would suffice.

test/jdk/java/text/Format/DecimalFormat/CloneTest.java line 81:

> 79:                             }
> 80:                         }
> 81:                     } catch (InterruptedException e) {

I'd suggest throwing the exception (or RuntimeException with it as the cause), not swallowing it silently in the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24598#discussion_r2045541029
PR Review Comment: https://git.openjdk.org/jdk/pull/24598#discussion_r2045546462

From duke at openjdk.org  Tue Apr 15 21:37:46 2025
From: duke at openjdk.org (Johannes Graham)
Date: Tue, 15 Apr 2025 21:37:46 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 15 Apr 2025 21:23:20 GMT, Naoto Sato  wrote:

>> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Terminate test early on failure
>
> test/jdk/java/text/Format/DecimalFormat/CloneTest.java line 77:
> 
>> 75:                             String str = String.valueOf(value);
>> 76:                             if (!str.equals(dfString)) {
>> 77:                                 mismatchCount.getAndIncrement();
> 
> `mismatchCount` is no longer needed. Simply break after printing the error message would suffice.

It would still need something to indicate that it had failed, as well as a way to signal other threads that they should terminate early. Worth changing to an AtomicBoolean?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24598#discussion_r2045572553

From naoto at openjdk.org  Tue Apr 15 21:43:41 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 15 Apr 2025 21:43:41 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: <3QrPHiZS_LdM_bbPBZp2YVQpop5JiKZDHA8hKb6u8_c=.9f428e2f-417c-4cd5-b6be-8931f2967f1a@github.com>

On Tue, 15 Apr 2025 21:34:21 GMT, Johannes Graham  wrote:

>> test/jdk/java/text/Format/DecimalFormat/CloneTest.java line 77:
>> 
>>> 75:                             String str = String.valueOf(value);
>>> 76:                             if (!str.equals(dfString)) {
>>> 77:                                 mismatchCount.getAndIncrement();
>> 
>> `mismatchCount` is no longer needed. Simply break after printing the error message would suffice.
>
> It would still need something to indicate that it had failed, as well as a way to signal other threads that they should terminate early. Worth changing to an AtomicBoolean?

Ah, ok then. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24598#discussion_r2045580939

From duke at openjdk.org  Tue Apr 15 21:47:32 2025
From: duke at openjdk.org (Johannes Graham)
Date: Tue, 15 Apr 2025 21:47:32 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v5]
In-Reply-To: 
References: 
Message-ID: 

> The `DigitList` class used in `DecimalFormat` does not reset the `data` array in its clone method. This can cause interference when clones are used concurrently.

Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:

  throw on InterruptedException

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24598/files
  - new: https://git.openjdk.org/jdk/pull/24598/files/dc5e466e..55b6183d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24598&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24598&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24598.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24598/head:pull/24598

PR: https://git.openjdk.org/jdk/pull/24598

From duke at openjdk.org  Tue Apr 15 21:50:46 2025
From: duke at openjdk.org (Johannes Graham)
Date: Tue, 15 Apr 2025 21:50:46 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v4]
In-Reply-To: <3QrPHiZS_LdM_bbPBZp2YVQpop5JiKZDHA8hKb6u8_c=.9f428e2f-417c-4cd5-b6be-8931f2967f1a@github.com>
References: 
 
 
 
 <3QrPHiZS_LdM_bbPBZp2YVQpop5JiKZDHA8hKb6u8_c=.9f428e2f-417c-4cd5-b6be-8931f2967f1a@github.com>
Message-ID: 

On Tue, 15 Apr 2025 21:40:56 GMT, Naoto Sato  wrote:

>> It would still need something to indicate that it had failed, as well as a way to signal other threads that they should terminate early. Worth changing to an AtomicBoolean?
>
> Ah, ok then. Thanks.

Ok to leave as is? Or is the AtomicBoolean more clear?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24598#discussion_r2045588599

From vklang at openjdk.org  Tue Apr 15 21:51:53 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 15 Apr 2025 21:51:53 GMT
Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth
 Preview) [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 15 Apr 2025 06:36:20 GMT, Alan Bateman  wrote:

>> Changes for [JEP 505: Structured Concurrency (Fifth Preview)](https://openjdk.org/jeps/8340343). The proposal is to re-preview the API with some changes, specifically:
>> 
>> - A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor.  Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close.
>> - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner.
>> - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions.
>> - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function.
>> - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method.
>>  
>> The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Add JEP number, update copyright headers
>  - Merge branch 'master' into JDK-8342486
>  - Sync up from loom repo
>  - Merge branch 'master' into JDK-8342486
>  - Sync up from loom repo
>  - Merge branch 'master' into JDK-8342486
>  - Merge branch 'master' into JDK-8342486
>  - Fix link
>  - Merge branch 'master' into JDK-8342486
>  - Sync up impl/tests form loom repo
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/3090e218...418bc3d3

Looks great, Alan. I made a couple of suggestions, primarily stylistic, but this PR is good to go as-is.

src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 496:

> 494:      * processed. It should be clear what the {@code Joiner} does vs. the application
> 495:      * code at the use-site. In general, the {@code Joiner} implementation is not the
> 496:      * place to code "business logic". A {@code Joiner} should be designed to be as

Suggestion:

     * place for "business logic". A {@code Joiner} should be designed to be as

src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 563:

> 561:          * 
 In normal usage, this method will be called at most once by the {@code join}
> 562:          * method to produce the result (or exception). The behavior of this method when
> 563:          * invoked directly, and invoked more than once, is not specified. Where possible,

Suggestion:

         * invoked directly, and invoked more than once, is undefined. Where possible,

src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 778:

> 776:         /**
> 777:          * {@return a new {@code Configuration} object with the given timeout}
> 778:          * The other components are the same as this object.

Suggestion:

         * The other other configuration options are preserved.

src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 806:

> 804:          * @param  cause the cause, can be {@code null}
> 805:          */
> 806:         public FailedException(Throwable cause) {

Should this be public?

src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 826:

> 824:          * Constructs a {@code TimeoutException} with no detail message.
> 825:          */
> 826:         public TimeoutException() { }

Should this be public?

src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 859:

> 857:      *
> 858:      * @param joiner the joiner
> 859:      * @param configFunction a function to produce the configuration

Suggestion:

     * @param configFunction a function to adapt the configuration

src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 948:

> 946:      * 
 This method returns the {@link Subtask Subtask} object. In some usages, this
> 947:      * object may be used to get its result. In other cases it may be used for correlation
> 948:      * or just discarded. To ensure correct usage, the {@link Subtask#get() Subtask.get()}

Suggestion:

     * or be discarded. To ensure correct usage, the {@link Subtask#get() Subtask.get()}

src/java.base/share/classes/java/util/concurrent/StructuredTaskScopeImpl.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.

No changes in 2025?

src/java.base/share/classes/java/util/concurrent/StructuredTaskScopeImpl.java line 424:

> 422:      * Used to schedule a task to cancel the scope when a timeout expires.
> 423:      */
> 424:     private static class TimerSupport {

Might make sense to use the commonPool():s DelayScheduler?

test/jdk/java/util/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java line 977:

> 975:             scope.fork(() -> "foo");
> 976:             while (!scope.isCancelled()) {
> 977:                 Thread.sleep(10);

Might make sense to create a utility method to "awaitAndAssertCancel" since this location has a 10ms sleep but others have a 20ms sleep. (To ensure that it is handled uniformly)

test/jdk/java/util/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java line 1394:

> 1392:             assertEquals(2, subtasks.size());
> 1393:             assertTrue(subtasks.get(0) == subtask1);
> 1394:             assertTrue(subtasks.get(1) == subtask2);

Stylistic, there's an "assertSame" to assert that two references refer to the same instance.

-------------

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21934#pullrequestreview-2768269128
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2044538364
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2044548316
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2045538271
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2045540091
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2045540261
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2045541888
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2045546116
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2045559901
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2045572893
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2045585721
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2045587907

From vklang at openjdk.org  Tue Apr 15 21:51:54 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 15 Apr 2025 21:51:54 GMT
Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth
 Preview) [v8]
In-Reply-To: <8KX_1xd1YhpEav0iSk_wvDEwnEJaEqwVl3KqgIN8p8c=.9813cb42-ab89-43c2-b0fb-f0b5d9955702@github.com>
References: 
 
 
 <8KX_1xd1YhpEav0iSk_wvDEwnEJaEqwVl3KqgIN8p8c=.9813cb42-ab89-43c2-b0fb-f0b5d9955702@github.com>
Message-ID: 

On Tue, 15 Apr 2025 13:38:21 GMT, Alan Bateman  wrote:

>> I'm not sure where we are on this topic. Clearly there's an edge between the pre-join and post-join phases.
>
> Yes, but it would be a topic for a different PR as we haven't changed anything here.

Agreed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2044619360

From ccheung at openjdk.org  Tue Apr 15 21:58:44 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 15 Apr 2025 21:58:44 GMT
Subject: RFR: 8352001: AOT cache should not contain classes injected into
 built-in class loaders [v2]
In-Reply-To: <8E5mTxKlKyx63Zm9-O7pvcpCEQWuXuB_BPyeWqhY0u8=.91c08221-3f6b-4e08-996c-444602f3a456@github.com>
References: 
 <8E5mTxKlKyx63Zm9-O7pvcpCEQWuXuB_BPyeWqhY0u8=.91c08221-3f6b-4e08-996c-444602f3a456@github.com>
Message-ID: <5-MJ1fv07BZTqXd09JXmRwbB4b9oP2ETPwVOevkuusM=.88ae6729-b686-42fa-bb3f-d0b87daaac6f@github.com>

On Sat, 12 Apr 2025 18:37:18 GMT, Ioi Lam  wrote:

>> During an application's training run, it's possible to inject classes into the built-in platform/app class loaders with reflection calls. 
>> 
>> - Before [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), only the names of these classes were recorded in the AOT config file. When the AOT cache is generated, these classes are automatically filtered out.
>> - Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), these classes are stored as parsed InstanceKlasses in the AOT config file, and will be transferred into the AOT cache. This new behavior may cause some applications to fail, as they may inject bytecodes that have environment dependencies.
>> 
>> For safety, this PR filters out such injected classes from the AOT config file.
>
> Ioi Lam 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 'master' into 8352001-exclude-injected-classes-from-builtin-loaders
>  - 8352001: AOT cache should not contain classes injected into built-in class loaders

Looks good overall. I have a question in classLoaderExt.cpp.

src/hotspot/share/classfile/classLoaderExt.cpp line 105:

> 103: 
> 104:   if (CDSConfig::is_dumping_preimage_static_archive() || CDSConfig::is_dumping_dynamic_archive()) {
> 105:     AOTClassLocationConfig::dumptime()->check_invalid_classpath_index(classpath_index, result);

In case the `classpath_index` is invalid, I don't think we should call `AOTClassLocationConfig::dumptime_update_max_used_index()`.  Maybe the `check_invalid_classpath_index()` function should return a bool and have `ClassLoaderExt::record_result()` update the classpath index and max used index.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24046#pullrequestreview-2769994967
PR Review Comment: https://git.openjdk.org/jdk/pull/24046#discussion_r2045596814

From roger.riggs at oracle.com  Tue Apr 15 22:04:35 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 15 Apr 2025 18:04:35 -0400
Subject: [External] : Re: My experience using Java to do CLI Scripting
In-Reply-To: <4570585B-0BFA-49DC-BA5F-4DE04110A6C0@oracle.com>
References: 
 <356624F4-6FE4-4D22-92EE-049C1E03472C@oracle.com>
 <0be34f61-8b4b-494d-bb4a-2d21fb3127e7@gmail.com>
 <1E97A470-8441-4DF6-B266-CE45956075F2@oracle.com>
 <778403719.226536541.1744663720524.JavaMail.zimbra@univ-eiffel.fr>
 <2caec135-cdb2-46d4-b46d-e6979f99b6ae@oracle.com>
 <1168340462.227175047.1744710667933.JavaMail.zimbra@univ-eiffel.fr>
 <4570585B-0BFA-49DC-BA5F-4DE04110A6C0@oracle.com>
Message-ID: 

Hi,

The cleanup of Process state is handled by the implementation.

On Linux it waits for the exitStatus and when the process exits, it 
captures the status, drains any pending input into local buffers and 
closes the file descriptors. When the streams and Process implementation 
are GC'd any remaining cleanup is done. A Cleaner is registered for each 
stream to close the file descriptor.

On Windows, the cleaner of the Process object is used to close the 
Windows handle. Each stream has its own Cleaner registration to close 
its handle when the objects are GC'd. If you've seen cases of leaking 
file descriptors, zombie processes, or handles, that's a bug (hopefully 
reproducible).

I'm not sure using T-W-R would make it more robust, there would be 
additional complexity in mixing synchronous cleanup with the 
asynchronous cleanup.

Most of awkwardness of the Process API is related to independent states 
of the streams and the exit status itself and whether the application 
interprets a non-zero exit status in relation to the end-of-input 
streams; that interpretation is related to the particular application 
spawned.

The Process API also doesn't help, except for the timed `waitFor()` with 
a process that doesn't terminate, an empty standard input but waiting 
for input, etc.

The doc could be clearer that it is unnecessary to explicitly handle all 
of the process elements; ignore the exit status from the application 
spawned unless it means something.? One unfortunate aspect of streams is 
the lack of a distinction between a premature end-of-stream vs an 
explicit we're-done-here.? Ignore the error stream if there's no reason 
to believe it has any useful information, that also depends on what 
application was spawned.

The simple cases can be easier to code and should be and the more 
involved cases should take better advantage of more recent language and 
runtime features.

YMMV, Roger

On 4/15/25 8:30 AM, Ron Pressler wrote:
>
>> On 15 Apr 2025, at 10:51, forax at univ-mlv.fr wrote:
>>
>> ----- Original Message -----
>>> From: "Stuart Marks" 
>>> To: "Remi Forax" , "Ron Pressler" , "David Alayachew"
>>> 
>>> Cc: "cay horstmann" , "core-libs-dev" 
>>> Sent: Tuesday, April 15, 2025 12:10:54 AM
>>> Subject: Re: My experience using Java to do CLI Scripting
>>>
>>> A few points here...
>>>
>>> It might be possible to get away without any Process-related cleanup. For one,
>>> there's no "close" method on Process or ProcessBuilder. The destroy() method
>>> will
>>> certainly clean up, but you don't want that; and waitFor() merely waits for
>>> termination but doesn't actually clean anything up.
>>>
>>> At least in the Unix ProcessImpl class, there's a bunch of infrastructure to
>>> handle
>>> exit of the underlying process, drain input from its stdout/stderr, and close
>>> the
>>> pipes. (I didn't look on Windows.) So setting aside termination, IOException,
>>> and
>>> what to do with stderr, it seems possible to just get the inputReader() and do
>>> something with the characters it emits.
>> You mean by making the Process Closeable ?
> It could make sense to make Process AutoCloseable similar to how ExecutorService now works, i.e. by having the close method call waitFor.
>
>>> Getting a stream of lines with lines() seems like a reasonable thing to do if
>>> you
>>> want to process the output line by line.
>> with the caveat that you have to close() the returned stream (like Files.lines()), something people will often forget.
>>
> The three Process streams are created (by default) whether you ever use them or not, so if you did have to close them, you?d need to do it every time you use Process. The reason is that the IO scaffolding (including ensuring cleanup) needs to be set up as soon as the process is started, before we know if you?re interested in reading the output. I think that if you want the streams to *not* be opened, you need to ask ProcessBuilder explicitly with ProcessBuilder.Redirect.DISCARD.
>
> It seems to me that on Unix, the pipes are all closed as soon as the process terminates. On Windows it?s more complicated and there may be Cleaners involved (and the buffering done by the OS rather than Java?), but on either platform it seems that it doesn?t matter whether you actually use the streams.
>
> Perhaps Roger can clarify, or correct me if I?m wrong.
>
>>> There are other possibilities, taking a nod from Files, which has methods
>>> readAllLines() and readString(). Putting similar methods on some class in the
>>> Reader
>>> family might help considerably here. Or you could call Reader.transferTo(Writer)
>>> that will send the characters to any Writer that might have a useful
>>> destination.
>> +1 for readAllInputLines() and readInputString() on Process.
> Wouldn?t it make more sense to add these to BufferedReader?
>
> ? Ron
>
>


From naoto at openjdk.org  Tue Apr 15 22:08:47 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 15 Apr 2025 22:08:47 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v4]
In-Reply-To: 
References: 
 
 
 
 <3QrPHiZS_LdM_bbPBZp2YVQpop5JiKZDHA8hKb6u8_c=.9f428e2f-417c-4cd5-b6be-8931f2967f1a@github.com>
 
Message-ID: <9uk_-ix50NOH9FWs9HXumGOya3HTYq7vQPnmrt401xM=.cb18430f-65f5-44e5-bec8-52691981d7e6@github.com>

On Tue, 15 Apr 2025 21:47:49 GMT, Johannes Graham  wrote:

>> Ah, ok then. Thanks.
>
> Ok to leave as is? Or is the AtomicBoolean more clear?

Ok to use it as a failure indicator (still I'd suggest breaking immediately after printing error)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24598#discussion_r2045607522

From duke at openjdk.org  Tue Apr 15 22:21:31 2025
From: duke at openjdk.org (Johannes Graham)
Date: Tue, 15 Apr 2025 22:21:31 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v6]
In-Reply-To: 
References: 
Message-ID: 

> The `DigitList` class used in `DecimalFormat` does not reset the `data` array in its clone method. This can cause interference when clones are used concurrently.

Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:

  break after mismatch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24598/files
  - new: https://git.openjdk.org/jdk/pull/24598/files/55b6183d..abda88ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24598&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24598&range=04-05

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24598.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24598/head:pull/24598

PR: https://git.openjdk.org/jdk/pull/24598

From serb at openjdk.org  Tue Apr 15 23:23:46 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 15 Apr 2025 23:23:46 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: 
References: 
 
Message-ID: <7k8Vqbwnc5gQLdLWy6DMG3ReD0O68knX8T1OH4bdRZ8=.058d8240-f58f-4459-bd1e-e92981d6ae9b@github.com>

On Mon, 14 Apr 2025 12:53:35 GMT, Magnus Ihse Bursie  wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim

can we also force this rule by the jcheck?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2807748235

From naoto at openjdk.org  Tue Apr 15 23:45:46 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 15 Apr 2025 23:45:46 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 15 Apr 2025 22:21:31 GMT, Johannes Graham  wrote:

>> The `DigitList` class used in `DecimalFormat` does not reset the `data` array in its clone method. This can cause interference when clones are used concurrently.
>
> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
> 
>   break after mismatch

I just wonder if we could do a white testing, ie, `df.digitList.data != df.clone().digitList.data` after `df.format(Math.PI)`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24598#issuecomment-2807781536

From amenkov at openjdk.org  Tue Apr 15 23:54:20 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 15 Apr 2025 23:54:20 GMT
Subject: RFR: 8354461: Update tests to disable streaming output for attach
 tools
Message-ID: 

The change is a preparation step to enable attach streaming output by default.
The fix updates a number of tests which fail with timeout in tier1..tier7 when attach streaming output is enabled.
Details in the first comment.
Testing: tier1..7 with enabled attach streaming output

-------------

Commit messages:
 - tests

Changes: https://git.openjdk.org/jdk/pull/24672/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24672&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354461
  Stats: 159 lines in 19 files changed: 44 ins; 56 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/24672.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24672/head:pull/24672

PR: https://git.openjdk.org/jdk/pull/24672

From amenkov at openjdk.org  Tue Apr 15 23:54:20 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 15 Apr 2025 23:54:20 GMT
Subject: RFR: 8354461: Update tests to disable streaming output for attach
 tools
In-Reply-To: 
References: 
Message-ID: 

On Tue, 15 Apr 2025 23:30:35 GMT, Alex Menkov  wrote:

> The change is a preparation step to enable attach streaming output by default.
> The fix updates a number of tests which fail with timeout in tier1..tier7 when attach streaming output is enabled.
> Details in the first comment.
> Testing: tier1..7 with enabled attach streaming output

The tests use the same scenario: test runs a tool (jcmd/jstack/jmap) to attach to the main test process and redirects the tool output for analysis.
We have 2 buffers here:
1. attach channel (socket or pipe depending on platform) - attach operation handler writes, the tool reads.
2. tool redirection buffer - the tool writes, test reads.
When attach operation is executes at safepoint, attach streaming output is enabled and the tool output is lengthy we can get both buffers full and the test hung:
- attach handler blocks on write operation (tool need to read from the socket/pipe);
- the tool reads data from attach channel and blocks writing the data to its stdout (need to read from redirected stream);
- test redirector reader cannot read because the VM is at safepoint executing attach operation.
To avoid the deadlocks the test are updated to disable attach streaming output (attach operation output is buffered and is sent after the operation is completed).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24672#issuecomment-2807765324

From liach at openjdk.org  Wed Apr 16 00:03:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Apr 2025 00:03:46 GMT
Subject: RFR: 8354300: Fields in String are not trusted
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Apr 2025 14:47:59 GMT, Per Minborg  wrote:

> This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and `j.l.String.hashIsZero`. This means the VM can trust these fields to never change which enables constant folding optimizations.
> 
> This PR is tested in tier1, tier2, tier3, and tier4 which all pass.

src/java.base/share/classes/java/lang/String.java line 183:

> 181:      * us to avoid recalculating this.
> 182:      */
> 183:     @Stable

Suggestion:

    // Marking hashIsZero stable is meaningless, as a read of `0` on hash blocks
    // constant folding of reading hashIsZero

A compromise. A stable on the hash field is a net improvement; we can investigate constant folding the zero hashes later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24625#discussion_r2045739565

From fyang at openjdk.org  Wed Apr 16 00:08:48 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 16 Apr 2025 00:08:48 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L [v8]
In-Reply-To: 
References: 
 
Message-ID: <0exy0s0on9e274HN29ECdNuB9D8_vwcW6plafjgXDMc=.c3ff7043-52b5-43c3-b488-8062b0178d29@github.com>

On Fri, 11 Apr 2025 10:48:34 GMT, Hamlin Li  wrote:

>> Hi,
>> Can you help to review this patch?
>> On riscv, CMoveI/L already were implemented, but there are some gap:
>> 1. CMoveI/L does not support comparison with float/double, corresponding tests are not turn on either.
>> 2. Some optimization of C2 is not turned on, e.g. `Phi -> CMove -> min_max`.
>> 3. lack of some corresponding performance tests.
>> 
>> Also there are some issue with current Zicond:
>> 1. UseZicond is turned on automatically by hwprobe, but jmh tests show that it's not always bring benefit, in some situation it even brings regression, the reason is the generated code by Zicond is much larger than branch version, in particular when it's in a loop and unrolled.
>> 
>> This patch on riscv is to:
>> 1. add CMoveI/L comparing float/double, and corresponding tests,
>> 2. enable more C2 optimization,
>> 3. add more benchmark tests,
>> 4. turn off UseZicond by default.
>> 
>> Thanks!
>> 
>> ## Performance
>> 
>> ### MinMax
>> test data
>> 
>> Benchmark | Mode | Cnt | Score - master | Score - master+UseZbb | Score - -master+UseZicond | Score - master+UseZicond+UseZbb | Score - cmovei | Score - cmovei+UseZbb | Score - cmovei+UseZicond | Score - cmovei+UseZicond+UseZbb | Error | Units | Opt (master/cmovei)
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> o.o.b.vm.compiler.IfMinMax.testReductionInt | avgt | 40 | 17152.075 | 17216.592 | 17272.493 | 17296.89 | 17127.844 | 17036.605 | 17299.333 | 17250.566 | 73.179 | ns/op | 1.001
>> o.o.b.vm.compiler.IfMinMax.testReductionLong | avgt | 40 | 19770.828 | 19967.578 | 20268.905 | 20166.165 | 20065.552 | 20059.095 | 20161.914 | 20151.295 | 131.428 | ns/op | 0.985
>> o.o.b.vm.compiler.IfMinMax.testSingleInt | avgt | 40 | 114.734 | 114.402 | 114.887 | 114.384 | 114.4 | 110.631 | 112.162 | 110.915 | 0.333 | ns/op | 1.003
>> o.o.b.vm.compiler.IfMinMax.testSingleLong | avgt | 40 | 121.53 | 121.711 | 120.91 | 121.665 | 121.309 | 120.57 | 118.639 | 119.373 | 0.451 | ns/op | 1.002
>> o.o.b.vm.compiler.IfMinMax.testVectorInt | avgt | 40 | 60130.165 | 60062.303 | 61839.776 | 61895.194 | 15887.398 | 15924.502 | 15874.835 | 15667.936 | 101.94 | ns/op | 3.785
>> o.o.b.vm.c...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minors

test/hotspot/jtreg/compiler/vectorapi/TestVectorTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2022, 2025,Oracle and/or its affiliates. All rights reserved.

The jcheck is complaining about a copyright format issue here. There should be a space after `2025,`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24490#discussion_r2045746966

From psandoz at openjdk.org  Wed Apr 16 00:30:58 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 16 Apr 2025 00:30:58 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 21:23:52 GMT, Vladimir Ivanov  wrote:

>> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
>> 
>> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
>> 
>> The patch consists of the following parts:
>>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
>> 
>> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
>> 
>> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
>> 
>> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
>> 
>> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
>> 
>> Thanks!
>
> Vladimir Ivanov 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 19 additional commits since the last revision:
> 
>  - Merge branch 'master' into vector.math.01.java
>  - RVV and SVE adjustments
>  - Merge branch 'master' into vector.math.01.java
>  - Fix windows-aarch64 build failure
>  - features_string -> cpu_info_string
>  - Reviews and Float64Vector-related fix
>  - Misc fixes and cleanups
>  - CPU features support
>  - Cleanup
>  - TODO list
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/cf1ff745...0ffed12f

src/hotspot/share/opto/vectorIntrinsics.cpp line 488:

> 486: // V binaryOp(long address, Class vClass, Class elementType, int length,
> 487: //            V v1, V v2,
> 488: //            BinaryOperation defaultImpl)

`debugName` parameter is missing

src/hotspot/share/opto/vectorIntrinsics.cpp line 555:

> 553: 
> 554:   const char* debug_name = "";
> 555:   const TypeInstPtr* debug_name_oop = gvn().type(argument(8))->isa_instptr();

Should that be:

  const TypeInstPtr* debug_name_oop = gvn().type(argument(6 + arity))->isa_instptr();

?
Placing the `debugName` parameter before the vector parameters makes it easier to reason about IMO.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2045762528
PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2045767847

From bpb at openjdk.org  Wed Apr 16 00:42:22 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 16 Apr 2025 00:42:22 GMT
Subject: RFR: 8354450: Using a File with a path containing a trailing space
 should fail when alternative data streams are disabled (win) [v2]
In-Reply-To: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
References: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
Message-ID: 

> In `java.io.WinNTFileSystem::isInvalid`, replace an insufficient test for file path validity with a sufficient test for file path invalidity. Also, add a new test.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8354450: Add specific conditional for trailing space; adjust test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24635/files
  - new: https://git.openjdk.org/jdk/pull/24635/files/9b700e13..8c82d246

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24635&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24635&range=00-01

  Stats: 27 lines in 2 files changed: 7 ins; 16 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24635.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24635/head:pull/24635

PR: https://git.openjdk.org/jdk/pull/24635

From iklam at openjdk.org  Wed Apr 16 00:51:23 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Apr 2025 00:51:23 GMT
Subject: RFR: 8352001: AOT cache should not contain classes injected into
 built-in class loaders [v3]
In-Reply-To: 
References: 
Message-ID: 

> During an application's training run, it's possible to inject classes into the built-in platform/app class loaders with reflection calls. 
> 
> - Before [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), only the names of these classes were recorded in the AOT config file. When the AOT cache is generated, these classes are automatically filtered out.
> - Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), these classes are stored as parsed InstanceKlasses in the AOT config file, and will be transferred into the AOT cache. This new behavior may cause some applications to fail, as they may inject bytecodes that have environment dependencies.
> 
> For safety, this PR filters out such injected classes from the AOT config file.

Ioi Lam 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 'master' into 8352001-exclude-injected-classes-from-builtin-loaders
 - @calvinccheung review
 - @matias9927 comment
 - Merge branch 'master' into 8352001-exclude-injected-classes-from-builtin-loaders
 - 8352001: AOT cache should not contain classes injected into built-in class loaders

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24046/files
  - new: https://git.openjdk.org/jdk/pull/24046/files/23327c27..b5d20c5c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24046&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24046&range=01-02

  Stats: 173980 lines in 248 files changed: 6834 ins; 166625 del; 521 mod
  Patch: https://git.openjdk.org/jdk/pull/24046.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24046/head:pull/24046

PR: https://git.openjdk.org/jdk/pull/24046

From iklam at openjdk.org  Wed Apr 16 00:57:51 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Apr 2025 00:57:51 GMT
Subject: RFR: 8352001: AOT cache should not contain classes injected into
 built-in class loaders [v2]
In-Reply-To: <5-MJ1fv07BZTqXd09JXmRwbB4b9oP2ETPwVOevkuusM=.88ae6729-b686-42fa-bb3f-d0b87daaac6f@github.com>
References: 
 <8E5mTxKlKyx63Zm9-O7pvcpCEQWuXuB_BPyeWqhY0u8=.91c08221-3f6b-4e08-996c-444602f3a456@github.com>
 <5-MJ1fv07BZTqXd09JXmRwbB4b9oP2ETPwVOevkuusM=.88ae6729-b686-42fa-bb3f-d0b87daaac6f@github.com>
Message-ID: 

On Tue, 15 Apr 2025 21:54:56 GMT, Calvin Cheung  wrote:

>> Ioi Lam 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 'master' into 8352001-exclude-injected-classes-from-builtin-loaders
>>  - 8352001: AOT cache should not contain classes injected into built-in class loaders
>
> src/hotspot/share/classfile/classLoaderExt.cpp line 105:
> 
>> 103: 
>> 104:   if (CDSConfig::is_dumping_preimage_static_archive() || CDSConfig::is_dumping_dynamic_archive()) {
>> 105:     AOTClassLocationConfig::dumptime()->check_invalid_classpath_index(classpath_index, result);
> 
> In case the `classpath_index` is invalid, I don't think we should call `AOTClassLocationConfig::dumptime_update_max_used_index()`.  Maybe the `check_invalid_classpath_index()` function should return a bool and have `ClassLoaderExt::record_result()` update the classpath index and max used index.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24046#discussion_r2045794966

From iklam at openjdk.org  Wed Apr 16 00:57:52 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Apr 2025 00:57:52 GMT
Subject: RFR: 8352001: AOT cache should not contain classes injected into
 built-in class loaders [v2]
In-Reply-To: <_32DT-oOx-LzIjYCoG8l7nykQ6kpIOMYRJAJHviPnE8=.fbf64a54-cde8-4283-a11d-9036016458ab@github.com>
References: 
 <8E5mTxKlKyx63Zm9-O7pvcpCEQWuXuB_BPyeWqhY0u8=.91c08221-3f6b-4e08-996c-444602f3a456@github.com>
 <_32DT-oOx-LzIjYCoG8l7nykQ6kpIOMYRJAJHviPnE8=.fbf64a54-cde8-4283-a11d-9036016458ab@github.com>
Message-ID: 

On Tue, 15 Apr 2025 19:49:55 GMT, Matias Saavedra Silva  wrote:

>> Ioi Lam 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 'master' into 8352001-exclude-injected-classes-from-builtin-loaders
>>  - 8352001: AOT cache should not contain classes injected into built-in class loaders
>
> test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/FakeCodeLocation.java line 122:
> 
>> 120:     // Define a class using Lookup.defineClass(). The ClassFileParser should see "__JVM_DefineClass__"
>> 121:     // as the source location, so this class will be excluded, as the location is not supported.
>> 122:     static void testWithLookup() throws Exception {
> 
> Should this test capture some kind of output or exception?

These classes are still loadable (just not from the CDS archive), so there aren't exceptions printed here. These lines check that the classes are not loaded from CDS:


        public void checkExecution(OutputAnalyzer out, RunMode runMode) throws Exception {
            if (isDumping(runMode)) {
                out.shouldMatch("cds,class.* FakeCodeLocationApp");
                out.shouldNotMatch("cds,class.* ClassNotInJar1");
                out.shouldNotMatch("cds,class.* ClassNotInJar2");
            }

            if (runMode.isProductionRun()) {
                out.shouldMatch("class,load.* FakeCodeLocationApp .*source: shared objects file");
                out.shouldNotMatch("class,load.* ClassNotInJar1 .*source: shared objects file");
                out.shouldNotMatch("class,load.* ClassNotInJar2 .*source: shared objects file");
            }
        }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24046#discussion_r2045799211

From xgong at openjdk.org  Wed Apr 16 01:40:51 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 16 Apr 2025 01:40:51 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 15 Apr 2025 17:43:52 GMT, Vladimir Ivanov  wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 198:
>> 
>>> 196:             if (vspecies.vectorBitSize() < 128) {
>>> 197:                 return false; // 64-bit vectors are not supported
>>> 198:             }
>> 
>> Thanks for your refactor. It's really a good job!  
>> 
>> It seems float type support 64-bit vector operations before (see https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp#L9835). Will this change the behavior of 64-bit float vector? Thanks!
>
> Thanks for taking a look. 
> 
> In the latest version, Float64Vector cases should be properly handled.

Oh, yes. That's right! Thanks and sorry for my distraction.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2045837608

From xgong at openjdk.org  Wed Apr 16 01:51:45 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 16 Apr 2025 01:51:45 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 16 Apr 2025 00:20:07 GMT, Paul Sandoz  wrote:

>> Vladimir Ivanov 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 19 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into vector.math.01.java
>>  - RVV and SVE adjustments
>>  - Merge branch 'master' into vector.math.01.java
>>  - Fix windows-aarch64 build failure
>>  - features_string -> cpu_info_string
>>  - Reviews and Float64Vector-related fix
>>  - Misc fixes and cleanups
>>  - CPU features support
>>  - Cleanup
>>  - TODO list
>>  - ... and 9 more: https://git.openjdk.org/jdk/compare/f025c30a...0ffed12f
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 488:
> 
>> 486: // V binaryOp(long address, Class vClass, Class elementType, int length,
>> 487: //            V v1, V v2,
>> 488: //            BinaryOperation defaultImpl)
> 
> `debugName` parameter is missing

It seems the function should be updated to `libraryBinaryOp` and `libraryUnaryOp`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2045846887

From jpai at openjdk.org  Wed Apr 16 02:00:45 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Apr 2025 02:00:45 GMT
Subject: RFR: 8354565: jtreg failure handler
 GatherProcessInfoTimeoutHandler has a leftover call to System.loadLibrary
In-Reply-To: 
References: 
Message-ID: 

On Tue, 15 Apr 2025 05:50:03 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this cleanup in the jtreg timeout handler `GatherProcessInfoTimeoutHandler`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8354565, this is a leftover after the change done in https://bugs.openjdk.java.net/browse/JDK-8268626. The `timeoutHandler` native test library is no longer built in the JDK, nor it is required by this `GatherProcessInfoTimeoutHandler`. 
> 
> I've verified that the `GatherProcessInfoTimeoutHandler` continues to function normally on macosx (x64/aarch64), linux(x64/aarch64) and windows (x64), by intentionally timing out a test and verifying that the `GatherProcessInfoTimeoutHandler` continues to gather the relevant diagnostics.

Thank you Alan and Kim for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24648#issuecomment-2807986200

From jpai at openjdk.org  Wed Apr 16 02:00:46 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Apr 2025 02:00:46 GMT
Subject: Integrated: 8354565: jtreg failure handler
 GatherProcessInfoTimeoutHandler has a leftover call to System.loadLibrary
In-Reply-To: 
References: 
Message-ID: <4emG32tE0Xv4LDYkwRTy1lxEt6gziQAPs2PVnjDXFAc=.9fdd9cd9-8fdf-4d55-8189-2de426d102dc@github.com>

On Tue, 15 Apr 2025 05:50:03 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this cleanup in the jtreg timeout handler `GatherProcessInfoTimeoutHandler`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8354565, this is a leftover after the change done in https://bugs.openjdk.java.net/browse/JDK-8268626. The `timeoutHandler` native test library is no longer built in the JDK, nor it is required by this `GatherProcessInfoTimeoutHandler`. 
> 
> I've verified that the `GatherProcessInfoTimeoutHandler` continues to function normally on macosx (x64/aarch64), linux(x64/aarch64) and windows (x64), by intentionally timing out a test and verifying that the `GatherProcessInfoTimeoutHandler` continues to gather the relevant diagnostics.

This pull request has now been integrated.

Changeset: 55264907
Author:    Jaikiran Pai 
URL:       https://git.openjdk.org/jdk/commit/5526490743a75786a40754b6805f4381ae2892b5
Stats:     12 lines in 1 file changed: 0 ins; 12 del; 0 mod

8354565: jtreg failure handler GatherProcessInfoTimeoutHandler has a leftover call to System.loadLibrary

Reviewed-by: alanb, kbarrett

-------------

PR: https://git.openjdk.org/jdk/pull/24648

From xgong at openjdk.org  Wed Apr 16 02:16:55 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 16 Apr 2025 02:16:55 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 21:23:52 GMT, Vladimir Ivanov  wrote:

>> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
>> 
>> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
>> 
>> The patch consists of the following parts:
>>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
>> 
>> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
>> 
>> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
>> 
>> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
>> 
>> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
>> 
>> Thanks!
>
> Vladimir Ivanov 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 19 additional commits since the last revision:
> 
>  - Merge branch 'master' into vector.math.01.java
>  - RVV and SVE adjustments
>  - Merge branch 'master' into vector.math.01.java
>  - Fix windows-aarch64 build failure
>  - features_string -> cpu_info_string
>  - Reviews and Float64Vector-related fix
>  - Misc fixes and cleanups
>  - CPU features support
>  - Cleanup
>  - TODO list
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/d3c46607...0ffed12f

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 240:

> 238:                 if (isAARCH64() && vspecies.vectorBitSize() > 128) {
> 239:                     return false; // FIXME: SVE support only for MAX shapes
> 240:                 }

SVE also supports operations for partial vector size, which means the vector size is smaller than MAX size. For example, if the max vector size of a SVE architecture is 512-bit, the FP vector operations with `VectorShape.S_256_BIT` are also supported. They are implemented with the same scalable math functions in SLEEF.

Hence, I think this check and the assertion in line-198 can be removed. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2045871389

From smarks at openjdk.org  Wed Apr 16 03:24:26 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 16 Apr 2025 03:24:26 GMT
Subject: RFR: 8354464: Additional cleanup setting up native.encoding [v2]
In-Reply-To: 
References: 
Message-ID: 

> Remove the #ifdef MACOSX from platform-independent System.c, which (on Mac) sets native.encoding from sprops.encoding or (on non-Mac Unix and Windows) sets native.encoding from sprops.sun_jnu_encoding. After this removal, the native.encoding property will be set from sprops.encoding and the sun.jnu.encoding property will be set from sprops.sun_jnu_encoding.
> 
> Change the windows java_props_md.c so that it initializes sprops.sun_jnu_encoding and then copies that value to sprops.encoding. Previously, sprops.encoding was initialized with data from other Windows APIs, but this value was ignored by platform-independent code, which was kind of confusing.
> 
> There are no changes to the Unix (Mac & non-Mac) platform-specific code. It already has code to set sprops.encoding and sprops.sun_jnu_encoding properly, including macOS-specific code to set the latter to UTF-8 unconditionally.
> 
> There should be no behavior changes on any platform.
> 
> I changed variable names in windows/java_props_md.c to make it clear that the values stored into them are unused. Of course there are other possibilities here, such as changing the interface to SetupI18nProps(). I'm open to suggestions.

Stuart Marks 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:

 - Move asserts into platform-independent code.
 - Merge branch 'master' into JDK-8354464-additional-cleanup-native-encoding
 - Rename variables to make clear they're not used.
 - 8354464: Additional cleanup setting up native.encoding

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24607/files
  - new: https://git.openjdk.org/jdk/pull/24607/files/328fdd27..37cd3ed2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24607&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24607&range=00-01

  Stats: 175846 lines in 316 files changed: 7409 ins; 167532 del; 905 mod
  Patch: https://git.openjdk.org/jdk/pull/24607.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24607/head:pull/24607

PR: https://git.openjdk.org/jdk/pull/24607

From smarks at openjdk.org  Wed Apr 16 03:24:27 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 16 Apr 2025 03:24:27 GMT
Subject: RFR: 8354464: Additional cleanup setting up native.encoding [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 15 Apr 2025 17:12:18 GMT, Naoto Sato  wrote:

>> src/java.base/share/native/libjava/System.c line 151:
>> 
>>> 149:     /* basic encoding properties, always non-NULL */
>>> 150:     PUTPROP(propArray, _native_encoding_NDX, sprops->encoding);
>>> 151:     PUTPROP(propArray, _sun_jnu_encoding_NDX, sprops->sun_jnu_encoding);
>> 
>> Since we now got rid of platform depenence here, would it make sense to perform non-null assertion in Java level here? I remember in the last PR we added `assert` in platform C code.
>
> `Java level` -> `Platform independent C level`
> Sorry

Good idea. Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24607#discussion_r2045929780

From prr at openjdk.org  Wed Apr 16 04:43:42 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 16 Apr 2025 04:43:42 GMT
Subject: RFR: 8354273: Restore even more pointless unicode characters to
 ASCII [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 10:36:31 GMT, Magnus Ihse Bursie  wrote:

>> As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213), I found some additional places where unicode characters are unnecessarily used instead of pure ASCII.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove incorrectly copied "?anchor"

src/java.xml/share/legal/xhtml11.md line 50:

> 48: or derived from [title and URI of the W3C document]."
> 49: 
> 50: Disclaimers ?anchor

Did that come from an upstream file ?

test/jdk/java/awt/geom/Path2D/GetBounds2DPrecisionTest.java line 193:

> 191:         if (str.length() >= DIGIT_COUNT) {
> 192:             str = str.substring(0,DIGIT_COUNT-1)+"...";
> 193:         }

How did you test this ? Please say more than tiers 1-3 .. because this test isn't run until tier4.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24567#discussion_r2046043831
PR Review Comment: https://git.openjdk.org/jdk/pull/24567#discussion_r2046047435

From forax at openjdk.org  Wed Apr 16 05:14:40 2025
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 16 Apr 2025 05:14:40 GMT
Subject: RFR: 8354300: Fields in String are not trusted
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 16 Apr 2025 00:01:18 GMT, Chen Liang  wrote:

>> This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and `j.l.String.hashIsZero`. This means the VM can trust these fields to never change which enables constant folding optimizations.
>> 
>> This PR is tested in tier1, tier2, tier3, and tier4 which all pass.
>
> src/java.base/share/classes/java/lang/String.java line 183:
> 
>> 181:      * us to avoid recalculating this.
>> 182:      */
>> 183:     @Stable
> 
> Suggestion:
> 
>     // Marking hashIsZero stable is meaningless, as a read of `0` on hash blocks
>     // constant folding of reading hashIsZero
> 
> A compromise. A stable on the hash field is a net improvement; we can investigate constant folding the zero hashes later.

yes ! I would write
"given the current implementation of hashCode(), marking hasIsZero @Stable is not useful for constant folding, as the field `hash` of value '0' is read first."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24625#discussion_r2046079733

From liach at openjdk.org  Wed Apr 16 05:41:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Apr 2025 05:41:48 GMT
Subject: RFR: 8354300: Fields in String are not trusted
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 16 Apr 2025 05:12:28 GMT, R?mi Forax  wrote:

>> src/java.base/share/classes/java/lang/String.java line 183:
>> 
>>> 181:      * us to avoid recalculating this.
>>> 182:      */
>>> 183:     @Stable
>> 
>> Suggestion:
>> 
>>     // Marking hashIsZero stable is meaningless, as a read of `0` on hash blocks
>>     // constant folding of reading hashIsZero
>> 
>> A compromise. A stable on the hash field is a net improvement; we can investigate constant folding the zero hashes later.
>
> yes ! I would write
> "given the current implementation of hashCode(), marking hasIsZero @Stable is not useful for constant folding, as the field `hash` of value '0' is read first."

Yep. To be more exact, JIT anticipates a read of `hash` to be non-zero at any future point instead of trusting it to be zero when it observes `hashIsZero == 1`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24625#discussion_r2046111256

From alanb at openjdk.org  Wed Apr 16 06:06:44 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Apr 2025 06:06:44 GMT
Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth
 Preview) [v8]
In-Reply-To: <4avbKRYklQvJdOqJoQZyMopzZ0GmZx9MYXS-dl2gPEE=.6297c48a-42f6-4106-8456-bffec459f672@github.com>
References: 
 
 <4avbKRYklQvJdOqJoQZyMopzZ0GmZx9MYXS-dl2gPEE=.6297c48a-42f6-4106-8456-bffec459f672@github.com>
Message-ID: 

On Tue, 15 Apr 2025 06:38:15 GMT, Chen Liang  wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - Add JEP number, update copyright headers
>>  - Merge branch 'master' into JDK-8342486
>>  - Sync up from loom repo
>>  - Merge branch 'master' into JDK-8342486
>>  - Sync up from loom repo
>>  - Merge branch 'master' into JDK-8342486
>>  - Merge branch 'master' into JDK-8342486
>>  - Fix link
>>  - Merge branch 'master' into JDK-8342486
>>  - Sync up impl/tests form loom repo
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/3090e218...418bc3d3
>
> src/java.base/share/classes/java/util/concurrent/Joiners.java line 190:
> 
>> 188:      * A joiner that returns a stream of all subtasks.
>> 189:      */
>> 190:     static class AllSubtasks implements Joiner>> {
> 
> Suggestion:
> 
>     static final class AllSubtasks implements Joiner>> {

All the others are (non-public) static final, this one was missed, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2046135304

From alanb at openjdk.org  Wed Apr 16 06:06:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Apr 2025 06:06:47 GMT
Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth
 Preview) [v8]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 15 Apr 2025 13:25:41 GMT, Viktor Klang  wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - Add JEP number, update copyright headers
>>  - Merge branch 'master' into JDK-8342486
>>  - Sync up from loom repo
>>  - Merge branch 'master' into JDK-8342486
>>  - Sync up from loom repo
>>  - Merge branch 'master' into JDK-8342486
>>  - Merge branch 'master' into JDK-8342486
>>  - Fix link
>>  - Merge branch 'master' into JDK-8342486
>>  - Sync up impl/tests form loom repo
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/3090e218...418bc3d3
>
> src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 496:
> 
>> 494:      * processed. It should be clear what the {@code Joiner} does vs. the application
>> 495:      * code at the use-site. In general, the {@code Joiner} implementation is not the
>> 496:      * place to code "business logic". A {@code Joiner} should be designed to be as
> 
> Suggestion:
> 
>      * place for "business logic". A {@code Joiner} should be designed to be as

Okay

> src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 563:
> 
>> 561:          * 
 In normal usage, this method will be called at most once by the {@code join}
>> 562:          * method to produce the result (or exception). The behavior of this method when
>> 563:          * invoked directly, and invoked more than once, is not specified. Where possible,
> 
> Suggestion:
> 
>          * invoked directly, and invoked more than once, is undefined. Where possible,

Okay

> src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 778:
> 
>> 776:         /**
>> 777:          * {@return a new {@code Configuration} object with the given timeout}
>> 778:          * The other components are the same as this object.
> 
> Suggestion:
> 
>          * The other other configuration options are preserved.

The class introduces them as components of the configuration rather than "options" so I think I'll leave this as is.

> src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 806:
> 
>> 804:          * @param  cause the cause, can be {@code null}
>> 805:          */
>> 806:         public FailedException(Throwable cause) {
> 
> Should this be public?

That's a good question, there is no reason for these constructors to be public.

> src/java.base/share/classes/java/util/concurrent/StructuredTaskScopeImpl.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.
> 
> No changes in 2025?

It was created in 2024, hasn't had any changes until the rename from Config -> Configuration.

> src/java.base/share/classes/java/util/concurrent/StructuredTaskScopeImpl.java line 424:
> 
>> 422:      * Used to schedule a task to cancel the scope when a timeout expires.
>> 423:      */
>> 424:     private static class TimerSupport {
> 
> Might make sense to use the commonPool():s DelayScheduler?

TimerSupport hasn't changed, and pre-dates the FJP work to support delayed tasks, so maybe now is the time to migrate it.

> test/jdk/java/util/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java line 1394:
> 
>> 1392:             assertEquals(2, subtasks.size());
>> 1393:             assertTrue(subtasks.get(0) == subtask1);
>> 1394:             assertTrue(subtasks.get(1) == subtask2);
> 
> Stylistic, there's an "assertSame" to assert that two references refer to the same instance.

Yes, indeed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2046135423
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2046135526
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2046136931
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2046137297
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2046138621
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2046139774
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2046144074

From jwaters at openjdk.org  Wed Apr 16 06:07:48 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 16 Apr 2025 06:07:48 GMT
Subject: RFR: 8342869: Errors related to unused code on Windows after
 8339120 in awt
In-Reply-To: 
References: 
Message-ID: 

On Wed, 23 Oct 2024 05:07:37 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/workspace/jdk/src/java.desktop/windows/...

No.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21655#issuecomment-2808470368

From alanb at openjdk.org  Wed Apr 16 06:12:44 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Apr 2025 06:12:44 GMT
Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth
 Preview) [v8]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 15 Apr 2025 21:45:10 GMT, Viktor Klang  wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - Add JEP number, update copyright headers
>>  - Merge branch 'master' into JDK-8342486
>>  - Sync up from loom repo
>>  - Merge branch 'master' into JDK-8342486
>>  - Sync up from loom repo
>>  - Merge branch 'master' into JDK-8342486
>>  - Merge branch 'master' into JDK-8342486
>>  - Fix link
>>  - Merge branch 'master' into JDK-8342486
>>  - Sync up impl/tests form loom repo
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/3090e218...418bc3d3
>
> test/jdk/java/util/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java line 977:
> 
>> 975:             scope.fork(() -> "foo");
>> 976:             while (!scope.isCancelled()) {
>> 977:                 Thread.sleep(10);
> 
> Might make sense to create a utility method to "awaitAndAssertCancel" since this location has a 10ms sleep but others have a 20ms sleep. (To ensure that it is handled uniformly)

That's a good suggestion, an awaitCancelled would avoid having this while loop in a number of tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2046150243

From duke at openjdk.org  Wed Apr 16 06:45:18 2025
From: duke at openjdk.org (erifan)
Date: Wed, 16 Apr 2025 06:45:18 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
Message-ID: 

This patch optimizes the following patterns:
For integer types:

(XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
    => (VectorMaskCmp src1 src2 ncond)
(XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
    => (VectorMaskCmp src1 src2 ncond)

cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond.

For float and double types:

(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
    => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
(XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
    => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))

cond can be eq or ne.

Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`:

Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4714008.434	1681.10365	1.41
testCompareGTMaskNotByte	ops/s	7910823.674	2993.367032	10245063.58	9774.75138	1.29
testCompareGTMaskNotInt		ops/s	1673393.928	3153.099431	2353654.521	1190.848583	1.4
testCompareGTMaskNotLong	ops/s	849405.9159	2432.858159	1177952.041	359.96413	1.38
testCompareGTMaskNotShort	ops/s	3339509.141	3339.976585	4711442.496	2673.364893	1.41
testCompareLEMaskNotByte	ops/s	7911340.004	3114.69191	10231626.5	27134.20035	1.29
testCompareLEMaskNotInt		ops/s	1675812.113	1340.969885	2353255.341	1452.4522	1.4
testCompareLEMaskNotLong	ops/s	848862.8036	6564.841731	1177763.623	539.290106	1.38
testCompareLEMaskNotShort	ops/s	3324951.54	2380.29473	4712116.251	1544.559684	1.41
testCompareLTMaskNotByte	ops/s	7910390.844	2630.861436	10239567.69	6487.441672	1.29
testCompareLTMaskNotInt		ops/s	1672180.09	995.238142	2353757.863	853.774734	1.4
testCompareLTMaskNotLong	ops/s	856502.2695	12276.82851	1177671.815	496.723302	1.37
testCompareLTMaskNotShort	ops/s	3325798.025	2412.702501	4711554.181	1779.302112	1.41
testCompareNEMaskNotByte	ops/s	7910002.518	2771.82477	10245315.33	16321.93935	1.29
testCompareNEMaskNotDouble	ops/s	863754.6022	523.140788	1179133.982	476.572178	1.36
testCompareNEMaskNotFloat	ops/s	1723321.883	2598.484803	2358492.186	877.1401	1.36
testCompareNEMaskNotInt		ops/s	1670288.841	751.774826	2354158.125	835.720163	1.4
testCompareNEMaskNotLong	ops/s	836327.6835	410.525466	1178178.825	308.757932	1.4
testCompareNEMaskNotShort	ops/s	3327815.841	1511.978763	4711379.136	2336.505531	1.41
testCompareUGEMaskNotByte	ops/s	7906699.024	3200.936474	10253843.74	15067.59401	1.29
testCompareUGEMaskNotInt	ops/s	1674003.923	3287.191727	2353340.666	951.381021	1.4
testCompareUGEMaskNotLong	ops/s	852424.5562	8920.408939	1177943.609	389.6621	1.38
testCompareUGEMaskNotShort	ops/s	3327255.858	1584.885143	4711622.355	1247.215277	1.41
testCompareUGTMaskNotByte	ops/s	7909249.189	4435.283667	10245541.34	10993.34739	1.29
testCompareUGTMaskNotInt	ops/s	1693713.433	20650.00213	2353153.787	1055.343846	1.38
testCompareUGTMaskNotLong	ops/s	851022.3395	7079.065268	1177910.677	538.604598	1.38
testCompareUGTMaskNotShort	ops/s	3327236.988	1616.886789	4711209.865	3098.494145	1.41
testCompareULEMaskNotByte	ops/s	7909350.825	3251.262342	10261449.03	7273.831341	1.29
testCompareULEMaskNotInt	ops/s	1672350.925	1545.304304	2353231.755	914.231193	1.4
testCompareULEMaskNotLong	ops/s	853349.4765	9804.906913	1177967.254	435.044367	1.38
testCompareULEMaskNotShort	ops/s	3325757.891	1555.062257	4712873.187	1650.986905	1.41
testCompareULTMaskNotByte	ops/s	7912218.621	2633.477744	10242095.98	21921.39902	1.29
testCompareULTMaskNotInt	ops/s	1673994.849	2672.507666	2353449.22	946.105757	1.4
testCompareULTMaskNotLong	ops/s	849032.5868	10406.06689	1177586.047	506.541456	1.38
testCompareULTMaskNotShort	ops/s	3328062.026	1892.991844	4713247.216	1855.983724	1.41


With option `-XX:UseSVE=0`:

Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
testCompareEQMaskNotByte	ops/s	7895961.919	72712.90804	7746493.731	71481.92938	0.98
testCompareEQMaskNotDouble	ops/s	789811.0455	384.493088	766473.7994	2216.581793	0.97
testCompareEQMaskNotFloat	ops/s	1806305.818	638.010451	1819616.613	3295.38958	1
testCompareEQMaskNotInt		ops/s	1815820.144	1225.336135	1849538.401	766.29902	1.01
testCompareEQMaskNotLong	ops/s	807336.492	335.451807	792732.9483	277.954432	0.98
testCompareEQMaskNotShort	ops/s	4818266.38	1927.862665	4668903.001	1922.782715	0.96
testCompareGEMaskNotByte	ops/s	7818439.678	75374.97739	16498003.98	41440.49653	2.11
testCompareGEMaskNotInt		ops/s	1815159.05	1090.912209	2372095.779	1664.397112	1.3
testCompareGEMaskNotLong	ops/s	804324.5575	2301.686878	927919.8507	371.766719	1.15
testCompareGEMaskNotShort	ops/s	4818966.563	2443.643652	5385561.038	29558.37423	1.11
testCompareGTMaskNotByte	ops/s	7893406.157	82687.74264	16470663.2	22165.55812	2.08
testCompareGTMaskNotInt		ops/s	1815316.812	915.894106	2370447.198	655.016338	1.3
testCompareGTMaskNotLong	ops/s	807019.456	526.525482	928079.0541	330.582693	1.15
testCompareGTMaskNotShort	ops/s	4820552.881	1684.247747	5355902.93	5893.2915	1.11
testCompareLEMaskNotByte	ops/s	7816263.323	79560.0015	16473621.19	56688.99585	2.1
testCompareLEMaskNotInt		ops/s	1814915.724	926.998625	2368790.306	932.594778	1.3
testCompareLEMaskNotLong	ops/s	806483.9	935.718082	928110.9074	407.096695	1.15
testCompareLEMaskNotShort	ops/s	4813660.241	6817.870509	5357107.852	10061.47975	1.11
testCompareLTMaskNotByte	ops/s	7838948.962	69136.4504	16424405.96	24464.75469	2.09
testCompareLTMaskNotInt		ops/s	1815056.833	1187.6453	2369892.187	1103.819634	1.3
testCompareLTMaskNotLong	ops/s	806602.1804	287.923365	928346.4118	617.682824	1.15
testCompareLTMaskNotShort	ops/s	4817940.643	2767.1509	5372537.84	15397.47169	1.11
testCompareNEMaskNotByte	ops/s	9078493.798	4630.339307	16484348.42	18925.88346	1.81
testCompareNEMaskNotDouble	ops/s	661769.6272	398.712981	926763.5839	1808.843788	1.4
testCompareNEMaskNotFloat	ops/s	1570527.252	563.642144	2312425.678	1815.844846	1.47
testCompareNEMaskNotInt		ops/s	1619146.58	626.793854	2369711.543	942.330478	1.46
testCompareNEMaskNotLong	ops/s	680201.5381	2252.836482	927808.6147	414.917863	1.36
testCompareNEMaskNotShort	ops/s	3763508.054	3622.560798	5367808.015	8591.466599	1.42
testCompareUGEMaskNotByte	ops/s	7886373.129	75917.74675	16480928.93	27524.31005	2.08
testCompareUGEMaskNotInt	ops/s	1815636.832	750.036241	2369683.015	901.609404	1.3
testCompareUGEMaskNotLong	ops/s	806862.5826	287.819616	928001.4394	361.063837	1.15
testCompareUGEMaskNotShort	ops/s	4820581.361	2098.537435	5375854.248	25619.40165	1.11
testCompareUGTMaskNotByte	ops/s	7891591.465	96614.93542	16410405.93	15012.37096	2.07
testCompareUGTMaskNotInt	ops/s	1814871.179	662.825588	2371325.903	1170.491164	1.3
testCompareUGTMaskNotLong	ops/s	804013.7658	2240.534209	928062.2169	531.306897	1.15
testCompareUGTMaskNotShort	ops/s	4818150.337	3051.717685	5381449.337	21212.34187	1.11
testCompareULEMaskNotByte	ops/s	7831540.628	81306.67253	16495250.78	38682.19675	2.1
testCompareULEMaskNotInt	ops/s	1814484.14	687.860656	2369265.075	940.609586	1.3
testCompareULEMaskNotLong	ops/s	807780.5749	769.876816	927538.0732	1278.267724	1.14
testCompareULEMaskNotShort	ops/s	4817437.42	5141.336541	5356183.359	7015.608124	1.11
testCompareULTMaskNotByte	ops/s	7849078.225	56753.59764	16395975.27	34043.67295	2.08
testCompareULTMaskNotInt	ops/s	1814328.226	2697.219111	2370700.47	1991.841988	1.3
testCompareULTMaskNotLong	ops/s	807166.8197	253.061506	927926.2803	252.933462	1.14
testCompareULTMaskNotShort	ops/s	4821098.216	1625.959044	5348980.243	4100.768121	1.1


Benchmarks on AMD EPYC 9124 16-Core Processor:
With option `-XX:UseAVX=3`:

Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
testCompareEQMaskNotByte	ops/s	16607323.35	1233692.631	18381557.66	1163201.522	1.1
testCompareEQMaskNotDouble	ops/s	2114285.245	58782.2534	2959946.353	43016.0445	1.39
testCompareEQMaskNotFloat	ops/s	4480874.437	89975.29074	6960151.436	64799.143	1.55
testCompareEQMaskNotInt		ops/s	4370906.91	51784.80889	6856955.043	313858.5504	1.56
testCompareEQMaskNotLong	ops/s	2080065.895	26762.06732	2939142.143	67179.05314	1.41
testCompareEQMaskNotShort	ops/s	7968282.563	210437.2781	12701214.56	473152.6407	1.59
testCompareGEMaskNotByte	ops/s	18419141.89	473408.9451	19880059.68	321638.0397	1.07
testCompareGEMaskNotInt		ops/s	4419015.62	77352.98633	7037639.227	151066.0383	1.59
testCompareGEMaskNotLong	ops/s	2147982.48	49227.42782	3000275.928	39298.75344	1.39
testCompareGEMaskNotShort	ops/s	8469039.613	17833.19707	12288229.49	244317.8812	1.45
testCompareGTMaskNotByte	ops/s	18728997.5	468328.8358	20544730.05	392264.6466	1.09
testCompareGTMaskNotInt		ops/s	4510009.705	78812.57357	7364629.942	70970.78473	1.63
testCompareGTMaskNotLong	ops/s	2124104.969	40917.89257	2953536.279	35199.19687	1.39
testCompareGTMaskNotShort	ops/s	8690557.621	311534.1159	12344017.51	457931.8741	1.42
testCompareLEMaskNotByte	ops/s	17758400.53	478383.4945	19209183.26	1143297.241	1.08
testCompareLEMaskNotInt		ops/s	4363664.862	43443.18063	7054093.064	78141.11476	1.61
testCompareLEMaskNotLong	ops/s	2068632.213	29844.78023	2954766.412	50667.22502	1.42
testCompareLEMaskNotShort	ops/s	8637608.548	183538.5511	12719010.27	473568.8825	1.47
testCompareLTMaskNotByte	ops/s	14406138.95	423105.0163	17292417.96	371386.9689	1.2
testCompareLTMaskNotInt		ops/s	4546707.266	131977.3144	7040483.394	213590.4657	1.54
testCompareLTMaskNotLong	ops/s	2123277.356	47243.21499	2848720.442	58896.97045	1.34
testCompareLTMaskNotShort	ops/s	7570169.363	649873.6295	11945383.75	988276.5955	1.57
testCompareNEMaskNotByte	ops/s	18274529.55	683396.7384	19081938.8	1118739.778	1.04
testCompareNEMaskNotDouble	ops/s	2112533.61	43295.50012	2912115.441	78189.51083	1.37
testCompareNEMaskNotFloat	ops/s	4628683.814	93817.07362	6967208.729	145135.8544	1.5
testCompareNEMaskNotInt		ops/s	4470900.214	75974.50842	7286913.662	116328.5277	1.62
testCompareNEMaskNotLong	ops/s	2134091.061	46377.94061	2934667.477	81675.46021	1.37
testCompareNEMaskNotShort	ops/s	8790384.287	396161.8599	13076858.35	286272.1155	1.48
testCompareUGEMaskNotByte	ops/s	18009150.9	660803.8886	17551258.33	1667014.843	0.97
testCompareUGEMaskNotInt	ops/s	4442928.74	83190.81019	6854088.277	329008.8901	1.54
testCompareUGEMaskNotLong	ops/s	2088357.736	71696.24791	2973202.26	63278.78974	1.42
testCompareUGEMaskNotShort	ops/s	8348624.02	116562.7876	12832250.78	546869.3006	1.53
testCompareUGTMaskNotByte	ops/s	17871101.25	800199.6321	19902619.81	214003.3262	1.11
testCompareUGTMaskNotInt	ops/s	4088304.421	137797.9723	7135454.33	124553.651	1.74
testCompareUGTMaskNotLong	ops/s	2070610.42	19881.82182	2991536.365	36260.60767	1.44
testCompareUGTMaskNotShort	ops/s	8637099.341	155822.1608	12756579.77	186068.199	1.47
testCompareULEMaskNotByte	ops/s	17940901.36	1258029.364	18932484.94	694554.6305	1.05
testCompareULEMaskNotInt	ops/s	4369177.511	74982.31936	6392773.082	550171.2266	1.46
testCompareULEMaskNotLong	ops/s	2135905.761	43693.63178	2877579.631	41651.56289	1.34
testCompareULEMaskNotShort	ops/s	8607710.544	132655.1676	12446370.04	441718.3035	1.44
testCompareULTMaskNotByte	ops/s	17409912.23	1033204.537	20607479.99	362000.5056	1.18
testCompareULTMaskNotInt	ops/s	4386455.9	119192.1635	6920123.264	186158.2845	1.57
testCompareULTMaskNotLong	ops/s	2064995.149	38622.2734	2988343.589	39037.90006	1.44
testCompareULTMaskNotShort	ops/s	8642182.752	230919.2442	13029582.09	437101.4923	1.5


The small amount of performance degradation is due to test fluctuations.

-------------

Commit messages:
 - 8354242: VectorAPI: combine vector not operation with compare

Changes: https://git.openjdk.org/jdk/pull/24674/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354242
  Stats: 1051 lines in 5 files changed: 1048 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24674.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24674/head:pull/24674

PR: https://git.openjdk.org/jdk/pull/24674

From pminborg at openjdk.org  Wed Apr 16 07:06:46 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 16 Apr 2025 07:06:46 GMT
Subject: RFR: 8354300: Fields in String are not trusted
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 16 Apr 2025 05:38:59 GMT, Chen Liang  wrote:

>> yes ! I would write
>> "given the current implementation of hashCode(), marking hasIsZero @Stable is not useful for constant folding, as the field `hash` of value '0' is read first."
>
> Yep. To be more exact, JIT anticipates a read of `hash` to be non-zero at any future point instead of trusting it to be zero when it observes `hashIsZero == 1`.

>From a theoretical point of view, there is nothing that prevents the VM from constant folding the case where `hash = 0` as the two sub-conditions in  `(h == 0 && !hashIsZero)` do not have any side effect. In theory, the VM could check both conditions and determine that `h = 0` is not trusted (as `hash` is not trusted because it is the default value) but `!hashIsZero` is trusted and `false` which means the entire expression is trusted to be `false`. However, the VM logic is not implemented in such a way.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24625#discussion_r2046225943

From pminborg at openjdk.org  Wed Apr 16 07:23:45 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 16 Apr 2025 07:23:45 GMT
Subject: RFR: 8354300: Fields in String are not trusted
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Apr 2025 14:47:59 GMT, Per Minborg  wrote:

> This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and `j.l.String.hashIsZero`. This means the VM can trust these fields to never change which enables constant folding optimizations.
> 
> This PR is tested in tier1, tier2, tier3, and tier4 which all pass.

As discussed, we could integrate the current PR and then revisit `j.l.String` later. I have raised a new issue for this:

https://bugs.openjdk.org/browse/JDK-8354777

The output of the attached benchmark in the `777 issue confirms zero hash values are not constant folded:


Benchmark                     Mode  Cnt  Score   Error  Units
StringHashCodeStatic.empty    avgt   15  5.774 ? 0.143  ns/op
StringHashCodeStatic.nonZero  avgt   15  0.571 ? 0.012  ns/op
StringHashCodeStatic.zero     avgt   15  4.039 ? 0.038  ns/op


Unless no one objects within a day or so, I will integrate this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24625#issuecomment-2808627521

From alanb at openjdk.org  Wed Apr 16 07:36:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Apr 2025 07:36:46 GMT
Subject: RFR: 8354450: Using a File with a path containing a trailing space
 should fail when alternative data streams are disabled (win) [v2]
In-Reply-To: 
References: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
 
Message-ID: <1EKMYPzdR0EfG8v9_hauG3wPMw0_cRATLZlg0LbE4ps=.049a55bc-797a-4eb4-9b4a-f20b02cafbe4@github.com>

On Wed, 16 Apr 2025 00:42:22 GMT, Brian Burkhalter  wrote:

>> In `java.io.WinNTFileSystem::isInvalid`, replace an insufficient test for file path validity with a sufficient test for file path invalidity. Also, add a new test.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8354450: Add specific conditional for trailing space; adjust test

src/java.base/windows/classes/java/io/WinNTFileSystem.java line 372:

> 370:         int len = pathname.length();
> 371:         if (len > 0 && pathname.charAt(len - 1) == ' ')
> 372:             return true;

Can you think about "foo \bar" case too?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24635#discussion_r2046283524

From tpushkin at openjdk.org  Wed Apr 16 07:52:43 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 16 Apr 2025 07:52:43 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v8]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 15 Apr 2025 17:59:41 GMT, Calvin Cheung  wrote:

>> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused imports
>
> src/java.base/share/classes/jdk/internal/misc/CDS.java line 390:
> 
>> 388:             @Override
>> 389:             public byte[] readClassFile(String className) throws IOException {
>> 390:                 final var subPath = className.replace('.', File.separatorChar).concat(".class");
> 
> Should File.separatorChar be ?/? ? (just like at line 369)

No, this is an intentional difference.

Here the string is then passed to `Path.of(...)` so it should definitely be `File.separatorChar` because this is what `Path.of(...)` expects.

Regarding line 369, the string is then passed to `JarFile.getEntry(String name)` ? I wasn't able to find the description of the format of the `name` parameter so I followed the way `URLClassLoader` does it, it uses `/` for loading from a JAR (and `File.separatorChar` for loading from a directory). This seems logical since JAR format is platform-independent.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2046316431

From mdoerr at openjdk.org  Wed Apr 16 07:56:47 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 16 Apr 2025 07:56:47 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: 
References: 
 
Message-ID: <_OtXyj0LCymmSCQhXmO-Ak_z5ZEYd5-tvqPp16TmXos=.8da4aecf-3538-4303-9b5a-2a59811642e0@github.com>

On Mon, 14 Apr 2025 12:53:35 GMT, Magnus Ihse Bursie  wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim

We get the following problem on AIX:

checking for locale to use... no UTF-8 locale found
configure: error: No UTF-8 locale found. This is required for building successfully.
configure exiting with result code 1

@varada1110, @JoKern65: Can you take a look, please?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2808717775

From alanb at openjdk.org  Wed Apr 16 08:18:39 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Apr 2025 08:18:39 GMT
Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth
 Preview) [v9]
In-Reply-To: 
References: 
Message-ID: 

> Changes for [JEP 505: Structured Concurrency (Fifth Preview)](https://openjdk.org/jeps/8340343). The proposal is to re-preview the API with some changes, specifically:
> 
> - A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor.  Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close.
> - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner.
> - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions.
> - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function.
> - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method.
>  
> The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Sync up from loom repo
 - Merge branch 'master' into JDK-8342486
 - Add JEP number, update copyright headers
 - Merge branch 'master' into JDK-8342486
 - Sync up from loom repo
 - Merge branch 'master' into JDK-8342486
 - Sync up from loom repo
 - Merge branch 'master' into JDK-8342486
 - Merge branch 'master' into JDK-8342486
 - Fix link
 - ... and 7 more: https://git.openjdk.org/jdk/compare/9a5c7b3f...2da9b292

-------------

Changes: https://git.openjdk.org/jdk/pull/21934/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21934&range=08
  Stats: 4039 lines in 14 files changed: 1821 ins; 1438 del; 780 mod
  Patch: https://git.openjdk.org/jdk/pull/21934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21934/head:pull/21934

PR: https://git.openjdk.org/jdk/pull/21934

From sgehwolf at openjdk.org  Wed Apr 16 08:25:54 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 16 Apr 2025 08:25:54 GMT
Subject: Integrated: 8354629: Test tools/jlink/ClassFileInMetaInfo.java fails
 on builds with configure option --enable-linkable-runtime
In-Reply-To: 
References: 
Message-ID: 

On Tue, 15 Apr 2025 13:09:31 GMT, Severin Gehwolf  wrote:

> Please review this trivial test-only fix. A new test introduced with [JDK-8353267](https://bugs.openjdk.org/browse/JDK-8353267) runs `jlink` using the `ToolProvider` API in-process. This is problematic for JEP 493 enabled builds which don't allow to be run on a patched JDK. Note that JTREG patches the JDK's `java.base` module with `JTRegModuleHelper` class. The fix is to run in `othervm` instead.
> 
> Testing:
> - [x] GHA
> - [x] jlink tests on a build with `--enable-linkable-runtime`. Shows the failure before and passes after.
> 
> Thoughts?

This pull request has now been integrated.

Changeset: 18d605fa
Author:    Severin Gehwolf 
URL:       https://git.openjdk.org/jdk/commit/18d605fadbd57090f5eb02c18e6e8860d9086515
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8354629: Test tools/jlink/ClassFileInMetaInfo.java fails on builds with configure option --enable-linkable-runtime

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/24661

From xgong at openjdk.org  Wed Apr 16 09:03:43 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 16 Apr 2025 09:03:43 GMT
Subject: RFR: 8351623: VectorAPI: Refactor subword gather load and add SVE
 implementation
Message-ID: 

### Summary:
[JDK-8318650](http://java-service.client.nvidia.com/?q=8318650) added the hotspot intrinsifying of subword gather load APIs for X86 platforms [1]. This patch aims at implementing the equivalent functionality for AArch64 SVE platform. In addition to the AArch64 backend support, this patch also refactors the API implementation in Java side and the compiler mid-end part to make the operations more efficient and maintainable across different architectures.

### Background:
Vector gather load APIs load values from memory addresses calculated by adding a base pointer to integer indices stored in an int array. SVE provides native vector gather load instructions for byte/short types using an int vector saving indices (see [2][3]).

The number of loaded elements must match the index vector's element count. Since int elements are 4/2 times larger than byte/short elements, and given `MaxVectorSize` constraints, the operation may need to be splitted into multiple parts.

Using a 128-bit byte vector gather load as an example, there are four scenarios with different `MaxVectorSize`:

1. `MaxVectorSize = 16, byte_vector_size = 16`:
   - Can load 4 indices per vector register
   - So can finish 4 bytes per gather-load operation
   - Requires 4 times of gather-loads and final merge
   Example:
   ```
   byte[] arr = [a, b, c, d, e, f, g, h, i, g, k, l, m, n, o, p, ...]
   int[] idx = [3, 2, 4, 1, 5, 7, 5, 2, 0, 6, 7, 1, 15, 10, 11, 9]

   4 gather-load:
   idx_v1 = [1 4 2 3]    gather_v1 = [0000 0000 0000 becd]
   idx_v2 = [2 5 7 5]    gather_v2 = [0000 0000 0000 cfhf]
   idx_v3 = [1 7 6 0]    gather_v3 = [0000 0000 0000 bhga]
   idx_v4 = [9 11 10 15] gather_v4 = [0000 0000 0000 jlkp]
   merge: v = [jlkp bhga cfhf becd]
   ```

2. `MaxVectorSize = 32, byte_vector_size = MaxVectorSize / 2`:
   - Can load 8 indices per vector register
   - So can finish 8 bytes per gather-load operation
   - Requires 2 times of gather-loads and merge
   Example:
   ```
   byte[] arr = [a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, ...]
   int[] index = [3, 2, 4, 1, 5, 7, 5, 2, 0, 6, 7, 1, 15, 10, 11, 9]

   2 gather-load:
   idx_v1 = [2 5 7 5 1 4 2 3]
   idx_v2 = [9 11 10 15 1 7 6 0]
   gather_v1 = [0000 0000 0000 0000 0000 0000 cfhf becd]
   gather_v2 = [0000 0000 0000 0000 0000 0000 jlkp bhga]
   merge: v = [0000 0000 0000 0000 jlkp bhga cfhf becd]
   ```

3. `MaxVectorSize = 64, byte_vector_size = MaxVectorSize / 4`:
   - Can load 16 indices per vector register
   - So can finish 16 bytes per gather-load operation
   - No splitting required
   Example:
   ```
   byte[] arr = [a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, ...]
   int[] index = [3, 2, 4, 1, 5, 7, 5, 2, 0, 6, 7, 1, 15, 10, 11, 9]

   1 gather-load:
   idx_v = [9 11 10 15 1 7 6 0 2 5 7 5 1 4 2 3]
   v = [... 0000 0000 0000 0000 jlkp bhga cfhf becd]
   ```

4. `MaxVectorSize > 64, byte_vector_size < MaxVectorSize / 4`:
   - Can load 32+ indices per vector register
   - So can finish 16 bytes per gather-load operation
   - Requires masking to allow loading 16 active elements to keep safe
     memory access.
   Example:
   ```
   byte[] arr = [a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, ...]
   int[] index = [3, 2, 4, 1, 5, 7, 5, 2, 0, 6, 7, 1, 15, 10, 11, 9]

   1 gather-load:
   idx_v = [... 0 0 0 0 0 0 0 0 9 11 10 15 1 7 6 0 2 5 7 5 1 4 2 3]
   v = [... 0000 0000 0000 0000 0000 jlkp bhga cfhf becd]
   ```

### Main changes:
1. Java-side API refactoring:
   - Potential multiple index vectors have been generated for index checking in java-side. This patch passes all the generated index vectors to hotspot to eliminate the duplicate index vectors used for the vector gather load operations on architectures like AArch64. Existing IGVN cannot work due to the different control flow of the index vectors generated in java-side and compiler intrinsifying.
2. C2 compiler IR refactoring:
   - Generate different IR patterns for different architectures like AArch64 and X86, based on the different index requirements.
   - Added two new IRs in C2 compiler to help implement each part of vector gather operation and merge the results at last.
   - Refactored the `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types. This patch removes the memory offset input and add it to the memory base `addr` in IR level for architectures that need the index array like X86. This not only simplifies the backend implementation, but also saves some add operations. Additionally, it unifies the IR for all types.
3. Backend changes:
   - Added SVE match rules for subword gather load operations and the new added IRs.
   - Refined the X86 implementation of subword gather since the offset input has been removed from the IR level.
4. Test:
   - Added IR tests for verification.

### Testing:
- Passed hotspot::tier1/2/3, jdk::tier1/2/3 tests
- Passed vector api tests with all `UseAVX
` flags on X86 and `UseSVE` flags on AArch64
- No regressions found

### Performance:
The performance of corresponding JMH benchmarks improve 3-11x on an NVIDIA GRACE CPU, which is a 128-bit SVE2 architecture. Following is the performance data:


Benchmark                                                (SIZE)   Mode Cnt  Units    Before     After    Gain
GatherOperationsBenchmark.microByteGather128                 64  thrpt  30  ops/ms  13447.414 43184.611  3.21
GatherOperationsBenchmark.microByteGather128                256  thrpt  30  ops/ms   3361.944 11165.006  3.32
GatherOperationsBenchmark.microByteGather128               1024  thrpt  30  ops/ms    843.501  2830.108  3.35
GatherOperationsBenchmark.microByteGather128               4096  thrpt  30  ops/ms    211.096   712.958  3.37
GatherOperationsBenchmark.microByteGather128_MASK            64  thrpt  30  ops/ms  10627.297 42818.402  4.02
GatherOperationsBenchmark.microByteGather128_MASK           256  thrpt  30  ops/ms   2675.144 11055.874  4.13
GatherOperationsBenchmark.microByteGather128_MASK          1024  thrpt  30  ops/ms    677.742  2783.920  4.10
GatherOperationsBenchmark.microByteGather128_MASK          4096  thrpt  30  ops/ms    169.416   686.783  4.05
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF     64  thrpt  30  ops/ms  10592.545 42282.802  3.99
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF    256  thrpt  30  ops/ms   2680.060 11039.563  4.11
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF   1024  thrpt  30  ops/ms    678.941  2790.252  4.10
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF   4096  thrpt  30  ops/ms    169.985   691.157  4.06
GatherOperationsBenchmark.microByteGather128_NZ_OFF          64  thrpt  30  ops/ms  13538.308 42954.988  3.17
GatherOperationsBenchmark.microByteGather128_NZ_OFF         256  thrpt  30  ops/ms   3414.237 11227.333  3.28
GatherOperationsBenchmark.microByteGather128_NZ_OFF        1024  thrpt  30  ops/ms    850.098  2821.821  3.31
GatherOperationsBenchmark.microByteGather128_NZ_OFF        4096  thrpt  30  ops/ms    213.295   705.015  3.30
GatherOperationsBenchmark.microByteGather64                  64  thrpt  30  ops/ms   8705.935 44213.982  5.07
GatherOperationsBenchmark.microByteGather64                 256  thrpt  30  ops/ms   2186.620 11407.364  5.21
GatherOperationsBenchmark.microByteGather64                1024  thrpt  30  ops/ms    545.364  2845.370  5.21
GatherOperationsBenchmark.microByteGather64                4096  thrpt  30  ops/ms    136.376   718.532  5.26
GatherOperationsBenchmark.microByteGather64_MASK             64  thrpt  30  ops/ms   6530.636 42053.044  6.43
GatherOperationsBenchmark.microByteGather64_MASK            256  thrpt  30  ops/ms   1644.069 11323.223  6.88
GatherOperationsBenchmark.microByteGather64_MASK           1024  thrpt  30  ops/ms    416.093  2844.712  6.83
GatherOperationsBenchmark.microByteGather64_MASK           4096  thrpt  30  ops/ms    105.777   716.685  6.77
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF      64  thrpt  30  ops/ms   6619.260 42204.919  6.37
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF     256  thrpt  30  ops/ms   1668.304 11318.298  6.78
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF    1024  thrpt  30  ops/ms    422.085  2844.398  6.73
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF    4096  thrpt  30  ops/ms    105.722   716.543  6.77
GatherOperationsBenchmark.microByteGather64_NZ_OFF           64  thrpt  30  ops/ms   8754.073 44232.985  5.05
GatherOperationsBenchmark.microByteGather64_NZ_OFF          256  thrpt  30  ops/ms   2195.009 11408.702  5.19
GatherOperationsBenchmark.microByteGather64_NZ_OFF         1024  thrpt  30  ops/ms    546.530  2845.369  5.20
GatherOperationsBenchmark.microByteGather64_NZ_OFF         4096  thrpt  30  ops/ms    137.713   718.391  5.21
GatherOperationsBenchmark.microShortGather128                64  thrpt  30  ops/ms   8695.558 33438.398  3.84
GatherOperationsBenchmark.microShortGather128               256  thrpt  30  ops/ms   2189.766  8533.643  3.89
GatherOperationsBenchmark.microShortGather128              1024  thrpt  30  ops/ms    546.322  2145.239  3.92
GatherOperationsBenchmark.microShortGather128              4096  thrpt  30  ops/ms    136.503   537.493  3.93
GatherOperationsBenchmark.microShortGather128_MASK           64  thrpt  30  ops/ms   6656.883 33571.619  5.04
GatherOperationsBenchmark.microShortGather128_MASK          256  thrpt  30  ops/ms   1649.233  8533.728  5.17
GatherOperationsBenchmark.microShortGather128_MASK         1024  thrpt  30  ops/ms    421.687  2135.280  5.06
GatherOperationsBenchmark.microShortGather128_MASK         4096  thrpt  30  ops/ms    105.355   537.418  5.10
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF    64  thrpt  30  ops/ms   6675.782 33441.402  5.00
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF   256  thrpt  30  ops/ms   1681.000  8532.770  5.07
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF  1024  thrpt  30  ops/ms    424.024  2135.485  5.03
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF  4096  thrpt  30  ops/ms    106.507   537.674  5.04
GatherOperationsBenchmark.microShortGather128_NZ_OFF         64  thrpt  30  ops/ms   8796.279 33441.738  3.80
GatherOperationsBenchmark.microShortGather128_NZ_OFF        256  thrpt  30  ops/ms   2198.774  8562.333  3.89
GatherOperationsBenchmark.microShortGather128_NZ_OFF       1024  thrpt  30  ops/ms    546.991  2133.496  3.90
GatherOperationsBenchmark.microShortGather128_NZ_OFF       4096  thrpt  30  ops/ms    137.191   537.390  3.91
GatherOperationsBenchmark.microShortGather64                 64  thrpt  30  ops/ms   5286.569 38042.434  7.19
GatherOperationsBenchmark.microShortGather64                256  thrpt  30  ops/ms   1312.778  9755.474  7.43
GatherOperationsBenchmark.microShortGather64               1024  thrpt  30  ops/ms    327.475  2450.755  7.48
GatherOperationsBenchmark.microShortGather64               4096  thrpt  30  ops/ms     82.490   613.481  7.43
GatherOperationsBenchmark.microShortGather64_MASK            64  thrpt  30  ops/ms   3525.102 37622.086  10.67
GatherOperationsBenchmark.microShortGather64_MASK           256  thrpt  30  ops/ms    877.877  9740.673  11.09
GatherOperationsBenchmark.microShortGather64_MASK          1024  thrpt  30  ops/ms    219.688  2446.063  11.13
GatherOperationsBenchmark.microShortGather64_MASK          4096  thrpt  30  ops/ms     54.935   613.137  11.16
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF     64  thrpt  30  ops/ms   3509.264 35147.895  10.01
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF    256  thrpt  30  ops/ms    880.523  9733.536  11.05
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF   1024  thrpt  30  ops/ms    220.578  2465.951  11.17
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF   4096  thrpt  30  ops/ms     55.790   620.465  11.12
GatherOperationsBenchmark.microShortGather64_NZ_OFF          64  thrpt  30  ops/ms   5271.218 35543.510  6.74
GatherOperationsBenchmark.microShortGather64_NZ_OFF         256  thrpt  30  ops/ms   1318.470  9735.321  7.38
GatherOperationsBenchmark.microShortGather64_NZ_OFF        1024  thrpt  30  ops/ms    328.695  2466.311  7.50
GatherOperationsBenchmark.microShortGather64_NZ_OFF        4096  thrpt  30  ops/ms     81.959   621.065  7.57



And here is the performance data on a X86 avx512 system, which shows the performance can improve at most 39%.


Benchmark                                                (SIZE)   Mode Cnt  Units    Before      After    Gain
GatherOperationsBenchmark.microByteGather128                 64  thrpt  30  ops/ms  44205.252  46829.437  1.05
GatherOperationsBenchmark.microByteGather128                256  thrpt  30  ops/ms  11243.202  12256.211  1.09
GatherOperationsBenchmark.microByteGather128               1024  thrpt  30  ops/ms   2824.094   3096.282  1.09
GatherOperationsBenchmark.microByteGather128               4096  thrpt  30  ops/ms    706.040    776.444  1.09
GatherOperationsBenchmark.microByteGather128_MASK            64  thrpt  30  ops/ms  46911.410  46321.310  0.98
GatherOperationsBenchmark.microByteGather128_MASK           256  thrpt  30  ops/ms  12850.712  12898.541  1.00
GatherOperationsBenchmark.microByteGather128_MASK          1024  thrpt  30  ops/ms   3099.038   3240.863  1.04
GatherOperationsBenchmark.microByteGather128_MASK          4096  thrpt  30  ops/ms    795.265    832.990  1.04
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF     64  thrpt  30  ops/ms  43065.930  47164.936  1.09
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF    256  thrpt  30  ops/ms  11537.805  13190.759  1.14
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF   1024  thrpt  30  ops/ms   2763.036   3304.582  1.19
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF   4096  thrpt  30  ops/ms    722.374    843.458  1.16
GatherOperationsBenchmark.microByteGather128_NZ_OFF          64  thrpt  30  ops/ms  44145.297  46845.845  1.06
GatherOperationsBenchmark.microByteGather128_NZ_OFF         256  thrpt  30  ops/ms  12172.421  12241.941  1.00
GatherOperationsBenchmark.microByteGather128_NZ_OFF        1024  thrpt  30  ops/ms   3097.042   3100.228  1.00
GatherOperationsBenchmark.microByteGather128_NZ_OFF        4096  thrpt  30  ops/ms    776.453    775.881  0.99
GatherOperationsBenchmark.microByteGather64                  64  thrpt  30  ops/ms  58541.178  59464.156  1.01
GatherOperationsBenchmark.microByteGather64                 256  thrpt  30  ops/ms  16063.284  17360.858  1.08
GatherOperationsBenchmark.microByteGather64                1024  thrpt  30  ops/ms   4126.798   4471.636  1.08
GatherOperationsBenchmark.microByteGather64                4096  thrpt  30  ops/ms   1045.116   1125.219  1.07
GatherOperationsBenchmark.microByteGather64_MASK             64  thrpt  30  ops/ms  35344.320  49062.831  1.38
GatherOperationsBenchmark.microByteGather64_MASK            256  thrpt  30  ops/ms  11946.622  13550.297  1.13
GatherOperationsBenchmark.microByteGather64_MASK           1024  thrpt  30  ops/ms   3275.053   3359.737  1.02
GatherOperationsBenchmark.microByteGather64_MASK           4096  thrpt  30  ops/ms    844.575    858.487  1.01
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF      64  thrpt  30  ops/ms  43550.522  48875.831  1.12
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF     256  thrpt  30  ops/ms  12216.995  13522.420  1.10
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF    1024  thrpt  30  ops/ms   3053.068   3391.067  1.11
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF    4096  thrpt  30  ops/ms    753.042    869.774  1.15
GatherOperationsBenchmark.microByteGather64_NZ_OFF           64  thrpt  30  ops/ms  52082.307  58847.230  1.12
GatherOperationsBenchmark.microByteGather64_NZ_OFF          256  thrpt  30  ops/ms  14210.930  17389.898  1.22
GatherOperationsBenchmark.microByteGather64_NZ_OFF         1024  thrpt  30  ops/ms   3697.996   4476.988  1.21
GatherOperationsBenchmark.microByteGather64_NZ_OFF         4096  thrpt  30  ops/ms    921.524   1125.308  1.22
GatherOperationsBenchmark.microShortGather128                64  thrpt  30  ops/ms  44325.212  44843.853  1.01
GatherOperationsBenchmark.microShortGather128               256  thrpt  30  ops/ms  11675.510  12630.103  1.08
GatherOperationsBenchmark.microShortGather128              1024  thrpt  30  ops/ms   1260.004   1373.395  1.09
GatherOperationsBenchmark.microShortGather128              4096  thrpt  30  ops/ms    761.857    814.790  1.06
GatherOperationsBenchmark.microShortGather128_MASK           64  thrpt  30  ops/ms  36339.450  36951.803  1.01
GatherOperationsBenchmark.microShortGather128_MASK          256  thrpt  30  ops/ms   9843.842  10018.754  1.01
GatherOperationsBenchmark.microShortGather128_MASK         1024  thrpt  30  ops/ms   2515.702   2595.312  1.03
GatherOperationsBenchmark.microShortGather128_MASK         4096  thrpt  30  ops/ms    616.450    661.402  1.07
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF    64  thrpt  30  ops/ms  34078.747  33712.577  0.98
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF   256  thrpt  30  ops/ms   9018.316   8515.947  0.94
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF  1024  thrpt  30  ops/ms   2250.813   2595.847  1.15
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF  4096  thrpt  30  ops/ms    563.182    659.087  1.17
GatherOperationsBenchmark.microShortGather128_NZ_OFF         64  thrpt  30  ops/ms  39909.543  44063.331  1.10
GatherOperationsBenchmark.microShortGather128_NZ_OFF        256  thrpt  30  ops/ms  10690.582  12437.166  1.16
GatherOperationsBenchmark.microShortGather128_NZ_OFF       1024  thrpt  30  ops/ms   2677.219   3151.078  1.17
GatherOperationsBenchmark.microShortGather128_NZ_OFF       4096  thrpt  30  ops/ms    681.705    802.929  1.17
GatherOperationsBenchmark.microShortGather64                 64  thrpt  30  ops/ms  45836.789  50883.505  1.11
GatherOperationsBenchmark.microShortGather64                256  thrpt  30  ops/ms  12269.355  13614.567  1.10
GatherOperationsBenchmark.microShortGather64               1024  thrpt  30  ops/ms   3010.548   3437.973  1.14
GatherOperationsBenchmark.microShortGather64               4096  thrpt  30  ops/ms    734.634    899.070  1.22
GatherOperationsBenchmark.microShortGather64_MASK            64  thrpt  30  ops/ms  39753.487  39319.742  0.98
GatherOperationsBenchmark.microShortGather64_MASK           256  thrpt  30  ops/ms  10615.540  10648.996  1.00
GatherOperationsBenchmark.microShortGather64_MASK          1024  thrpt  30  ops/ms   2653.485   2782.477  1.04
GatherOperationsBenchmark.microShortGather64_MASK          4096  thrpt  30  ops/ms    678.165    686.024  1.01
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF     64  thrpt  30  ops/ms  37742.593  40491.965  1.07
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF    256  thrpt  30  ops/ms  10096.251  11036.785  1.09
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF   1024  thrpt  30  ops/ms   2526.374   2812.550  1.11
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF   4096  thrpt  30  ops/ms    642.484    656.152  1.02
GatherOperationsBenchmark.microShortGather64_NZ_OFF          64  thrpt  30  ops/ms  40602.930  50921.048  1.25
GatherOperationsBenchmark.microShortGather64_NZ_OFF         256  thrpt  30  ops/ms  10972.083  14151.666  1.28
GatherOperationsBenchmark.microShortGather64_NZ_OFF        1024  thrpt  30  ops/ms   2726.248   3662.293  1.34
GatherOperationsBenchmark.microShortGather64_NZ_OFF        4096  thrpt  30  ops/ms    670.735    933.299  1.39


[1] https://bugs.openjdk.org/browse/JDK-8318650
[2] https://developer.arm.com/documentation/ddi0602/2024-12/SVE-Instructions/LD1B--scalar-plus-vector---Gather-load-unsigned-bytes-to-vector--vector-index--?lang=en
[3] https://developer.arm.com/documentation/ddi0602/2024-12/SVE-Instructions/LD1H--scalar-plus-vector---Gather-load-unsigned-halfwords-to-vector--vector-index--?lang=en

-------------

Commit messages:
 - 8351623: VectorAPI: Refactor subword gather load and add SVE implementation

Changes: https://git.openjdk.org/jdk/pull/24679/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24679&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351623
  Stats: 1367 lines in 34 files changed: 915 ins; 180 del; 272 mod
  Patch: https://git.openjdk.org/jdk/pull/24679.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24679/head:pull/24679

PR: https://git.openjdk.org/jdk/pull/24679

From myankelevich at openjdk.org  Wed Apr 16 09:46:36 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 16 Apr 2025 09:46:36 GMT
Subject: RFR: 8354450: Using a File with a path containing a trailing space
 should fail when alternative data streams are disabled (win) [v2]
In-Reply-To: 
References: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
 
Message-ID: <__CAYO4goU7x0Ee-m-8kgQ-JacRiqXsMPcEJE-hcA1o=.b01de7fd-1214-4cda-a7d8-257ab22f7ae6@github.com>

On Wed, 16 Apr 2025 00:42:22 GMT, Brian Burkhalter  wrote:

>> In `java.io.WinNTFileSystem::isInvalid`, replace an insufficient test for file path validity with a sufficient test for file path invalidity. Also, add a new test.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8354450: Add specific conditional for trailing space; adjust test

test/jdk/java/io/File/WinTrailingSpace.java line 28:

> 26: 
> 27: import org.junit.jupiter.api.Test;
> 28: import static org.junit.jupiter.api.Assertions.*;

nitpick: wildcard import

test/jdk/java/io/File/WinTrailingSpace.java line 61:

> 59:             f.delete();
> 60:             f.createNewFile();
> 61:             assertFalse(f.exists()); // should not reach here

Do you think this might be easier to debug if there was a message in there rather than an `assertFalse`? In case of an error this will just say failed. However in the failed case where the file wasn't actually created and the error wasn't triggered either it should pass in the current state. This will be more confusing when debugging, especially in case of an intermittent issue.
 My feeling is that for the long run it might be better to have something like 
```java 
assertFalse("File was created. File exists", f.exists());
assertEquals("No error thrown", "Error Thrown"); 


What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24635#discussion_r2046493405
PR Review Comment: https://git.openjdk.org/jdk/pull/24635#discussion_r2046509227

From ihse at openjdk.org  Wed Apr 16 09:50:49 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Apr 2025 09:50:49 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <7k8Vqbwnc5gQLdLWy6DMG3ReD0O68knX8T1OH4bdRZ8=.058d8240-f58f-4459-bd1e-e92981d6ae9b@github.com>
References: 
 
 <7k8Vqbwnc5gQLdLWy6DMG3ReD0O68knX8T1OH4bdRZ8=.058d8240-f58f-4459-bd1e-e92981d6ae9b@github.com>
Message-ID: 

On Tue, 15 Apr 2025 23:20:45 GMT, Sergey Bylokhov  wrote:

> can we also force this rule by the jcheck?

Well, yes and no. First, we can verify that we do not have invalid UTF-8. That might be a signal that the encoding is wrong. But then this check needs to be able to distinguish between pure binary files that happen to look like improperly encoded UTF-8 files, and actually incorrectly encoded text files. In the end, this is likely to be more of an heuristic for a warning, rather than something we can block integration on.

Secondly, files can have incorrect encodings but still pass as valid UTF-8. Only a human can tell that the content would be incorrect if we were to assume the encoding is UTF-8 instead of e.g. latin-1. This cannot be checked by jcheck, but must be caught by reviewers.

I have beeb thinking, though, to add a warning to jcheck for adding non-ASCII characters to known text file types. As a general rule, this is acceptable but should only be done judiciously, so it would be good to have jcheck point it out. That would also give you an extra chance to verify the encoding.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2809028487

From ihse at openjdk.org  Wed Apr 16 09:55:40 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Apr 2025 09:55:40 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <_OtXyj0LCymmSCQhXmO-Ak_z5ZEYd5-tvqPp16TmXos=.8da4aecf-3538-4303-9b5a-2a59811642e0@github.com>
References: 
 
 <_OtXyj0LCymmSCQhXmO-Ak_z5ZEYd5-tvqPp16TmXos=.8da4aecf-3538-4303-9b5a-2a59811642e0@github.com>
Message-ID: <6Kyy5kYllWxxLc6k2u-dF9dqmPcEQS74vEJO8rWG-D0=.0adee9b2-334c-473c-b0cc-1cbeb2774df6@github.com>

On Wed, 16 Apr 2025 07:54:13 GMT, Martin Doerr  wrote:

> We get the following problem on AIX:
> 
> ```
> checking for locale to use... no UTF-8 locale found
> configure: error: No UTF-8 locale found. This is required for building successfully.
> configure exiting with result code 1
> ```

This is (hopefully) more of a configuration issue than an issue with AIX per se. You can run `locale -a` to see all available locales, and see if there is any utf-8 locales at all. It might be that the naming scheme does not match `*.UTF-8`. Otherwise, you'd have to install the `C.UTF-8` or `en_US.UTF-8` locale. 

If no UTF-8 locales are available at all on AIX, then we might have to add some kind of exception. But beware that you will be building on an unsupported configuration in that case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2809035830

From mdoerr at openjdk.org  Wed Apr 16 10:11:46 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 16 Apr 2025 10:11:46 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <6Kyy5kYllWxxLc6k2u-dF9dqmPcEQS74vEJO8rWG-D0=.0adee9b2-334c-473c-b0cc-1cbeb2774df6@github.com>
References: 
 
 <_OtXyj0LCymmSCQhXmO-Ak_z5ZEYd5-tvqPp16TmXos=.8da4aecf-3538-4303-9b5a-2a59811642e0@github.com>
 <6Kyy5kYllWxxLc6k2u-dF9dqmPcEQS74vEJO8rWG-D0=.0adee9b2-334c-473c-b0cc-1cbeb2774df6@github.com>
Message-ID: 

On Wed, 16 Apr 2025 09:51:49 GMT, Magnus Ihse Bursie  wrote:

> `locale -a`


C
POSIX
en_US.8859-15
en_US.IBM-858
en_US.ISO8859-1
en_US


I don't know if UTF-8 can be installed. If so, we should also document that as requirement for AIX build machines.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2809046398

From ihse at openjdk.org  Wed Apr 16 10:11:52 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Apr 2025 10:11:52 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 14 Apr 2025 12:53:35 GMT, Magnus Ihse Bursie  wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim

? It's kind of a wonder that you have been able to build at all so far..!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2809055178

From ihse at openjdk.org  Wed Apr 16 10:11:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Apr 2025 10:11:57 GMT
Subject: RFR: 8354273: Restore even more pointless unicode characters to
 ASCII [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 16 Apr 2025 04:39:22 GMT, Phil Race  wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove incorrectly copied "?anchor"
>
> src/java.xml/share/legal/xhtml11.md line 50:
> 
>> 48: or derived from [title and URI of the W3C document]."
>> 49: 
>> 50: Disclaimers ?anchor
> 
> Did that come from an upstream file ?

No, it is copy/pasted from a textual rendering of the html file specified in the URL above. This is what you get if you na?vely select the text in Firefox and press Ctrl-C. The `?anchor` part is not rendered on screen.

> test/jdk/java/awt/geom/Path2D/GetBounds2DPrecisionTest.java line 193:
> 
>> 191:         if (str.length() >= DIGIT_COUNT) {
>> 192:             str = str.substring(0,DIGIT_COUNT-1)+"...";
>> 193:         }
> 
> How did you test this ? Please say more than tiers 1-3 .. because this test isn't run until tier4.

I did not test tier4. Will do so now. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24567#discussion_r2046572753
PR Review Comment: https://git.openjdk.org/jdk/pull/24567#discussion_r2046573122

From mbaesken at openjdk.org  Wed Apr 16 10:37:42 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 16 Apr 2025 10:37:42 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 14 Apr 2025 12:53:35 GMT, Magnus Ihse Bursie  wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim

make/autoconf/basic.m4 line 155:

> 153:       else
> 154:         AC_MSG_RESULT([no UTF-8 locale found])
> 155:         AC_MSG_ERROR([No UTF-8 locale found. This is required for building successfully.])

Seems we run into this 'else' part  on  AIX


checking for locale to use... no UTF-8 locale found
configure: error: No UTF-8 locale found. This is required for building successfully.
configure exiting with result code 1

maybe it would be nice to display the desired ones C.UTF-8 or en_US.UTF-8 in this message too for more clarity?  (have to check if there are other names on AIX)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24574#discussion_r2046642699

From duke at openjdk.org  Wed Apr 16 10:37:51 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 16 Apr 2025 10:37:51 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: 
References: 
 
 
Message-ID: <6dAYgfNcUgA3z3iid8wXPNo3qhdhZGDbCgOfbfA0skE=.8194c6ee-81df-4170-a983-0283c2234d0b@github.com>

On Tue, 15 Apr 2025 20:46:52 GMT, Roger Riggs  wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'
>
> src/java.base/share/classes/java/lang/CharSequence.java line 338:
> 
>> 336:      * Concurrent truncation of this character sequence can throw
>> 337:      * {@code IndexOutOfBoundsException}. In this case, some characters, but not
>> 338:      * all, may be already transferred.
> 
> Though its been absent for decades, it might be worthwhile to include a class level warning that the implementations of the interface are not known or required to be thread safe and if used concurrently by multiple threads the behavior is unpredictable.  I'd be more circumspect than trying to specify the only aberrant behavior is IndexOutOfBounds.

Any quick proposals how to rephrase JavaDocs and CSR? As the CSR is already reviewed I am a bit reluctant to hold the train for this, as IMHO *masses* of classes and interfaces would need such a disclaimer, if we kick-off that ball here...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2046642887

From alanb at openjdk.org  Wed Apr 16 10:44:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Apr 2025 10:44:50 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <6dAYgfNcUgA3z3iid8wXPNo3qhdhZGDbCgOfbfA0skE=.8194c6ee-81df-4170-a983-0283c2234d0b@github.com>
References: 
 
 
 <6dAYgfNcUgA3z3iid8wXPNo3qhdhZGDbCgOfbfA0skE=.8194c6ee-81df-4170-a983-0283c2234d0b@github.com>
Message-ID: 

On Wed, 16 Apr 2025 10:35:10 GMT, Markus KARG  wrote:

>> src/java.base/share/classes/java/lang/CharSequence.java line 338:
>> 
>>> 336:      * Concurrent truncation of this character sequence can throw
>>> 337:      * {@code IndexOutOfBoundsException}. In this case, some characters, but not
>>> 338:      * all, may be already transferred.
>> 
>> Though its been absent for decades, it might be worthwhile to include a class level warning that the implementations of the interface are not known or required to be thread safe and if used concurrently by multiple threads the behavior is unpredictable.  I'd be more circumspect than trying to specify the only aberrant behavior is IndexOutOfBounds.
>
> Any quick proposals how to rephrase JavaDocs and CSR? As the CSR is already reviewed I am a bit reluctant to hold the train for this, as IMHO *masses* of classes and interfaces would need such a disclaimer, if we kick-off that ball here...

I think Roger's suggestion is for a different JBS issue / PR / CSR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2046653580

From jpai at openjdk.org  Wed Apr 16 11:30:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Apr 2025 11:30:01 GMT
Subject: Integrated: Merge ed30fce6df57b1cbf7a6efebabc3558550f8ec16
Message-ID: 

This brings in the CPU25_04 changes into the master branch.

-------------

Commit messages:


The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/24683/files
  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24683.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24683/head:pull/24683

PR: https://git.openjdk.org/jdk/pull/24683

From dfuchs at openjdk.org  Wed Apr 16 11:30:01 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 16 Apr 2025 11:30:01 GMT
Subject: Integrated: Merge ed30fce6df57b1cbf7a6efebabc3558550f8ec16
In-Reply-To: 
References: 
Message-ID: 

On Wed, 16 Apr 2025 11:20:36 GMT, Jaikiran Pai  wrote:

> This brings in the CPU25_04 changes into the master branch.

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24683#pullrequestreview-2772164693

From jpai at openjdk.org  Wed Apr 16 11:30:02 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Apr 2025 11:30:02 GMT
Subject: Integrated: Merge ed30fce6df57b1cbf7a6efebabc3558550f8ec16
In-Reply-To: 
References: 
Message-ID: <5aoSWv3V3dVlk0FcmcAt3FpvLoE6CxWrTpYmPU5wyfw=.99fdb614-63cc-4cef-8442-b9d55f328d37@github.com>

On Wed, 16 Apr 2025 11:20:36 GMT, Jaikiran Pai  wrote:

> This brings in the CPU25_04 changes into the master branch.

Thank you Daniel for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24683#issuecomment-2809280611

From jpai at openjdk.org  Wed Apr 16 11:30:02 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Apr 2025 11:30:02 GMT
Subject: Integrated: Merge ed30fce6df57b1cbf7a6efebabc3558550f8ec16
In-Reply-To: 
References: 
Message-ID: 

On Wed, 16 Apr 2025 11:20:36 GMT, Jaikiran Pai  wrote:

> This brings in the CPU25_04 changes into the master branch.

This pull request has now been integrated.

Changeset: c6243fc2
Author:    Jaikiran Pai 
URL:       https://git.openjdk.org/jdk/commit/c6243fc27fafb1ff89f8610ead3acd87030caf95
Stats:     301 lines in 11 files changed: 223 ins; 25 del; 53 mod

Merge

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/24683

From jlahoda at openjdk.org  Wed Apr 16 12:07:45 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 16 Apr 2025 12:07:45 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console() [v4]
In-Reply-To: 
References: 
Message-ID: 

> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell.
> 
> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend.
> 
> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review feedback: Adding makefile comment as suggested

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24242/files
  - new: https://git.openjdk.org/jdk/pull/24242/files/daa2cc39..d75641e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24242&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24242&range=02-03

  Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24242.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24242/head:pull/24242

PR: https://git.openjdk.org/jdk/pull/24242

From duke at openjdk.org  Wed Apr 16 12:17:23 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 16 Apr 2025 12:17:23 GMT
Subject: RFR: 8354424: java/util/logging/LoggingDeadlock5.java fails
 intermittently in tier6
Message-ID: 

Increasing timeout for deadlock detection and adjusting for the timeout factor in higher tiers.

-------------

Commit messages:
 - Increasing timeout for deadlock detection.

Changes: https://git.openjdk.org/jdk/pull/24687/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24687&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354424
  Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24687.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24687/head:pull/24687

PR: https://git.openjdk.org/jdk/pull/24687

From dfuchs at openjdk.org  Wed Apr 16 13:21:42 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 16 Apr 2025 13:21:42 GMT
Subject: RFR: 8354424: java/util/logging/LoggingDeadlock5.java fails
 intermittently in tier6
In-Reply-To: 
References: 
Message-ID: 

On Wed, 16 Apr 2025 12:12:14 GMT, David Beaumont  wrote:

> Increasing timeout for deadlock detection and adjusting for the timeout factor in higher tiers.

Hard to tell whether 1s would be enough. I'd be tempted to bump that up.
You should also take the test out of the problem list.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24687#pullrequestreview-2772509199

From alanb at openjdk.org  Wed Apr 16 13:22:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Apr 2025 13:22:57 GMT
Subject: RFR: 8354464: Additional cleanup setting up native.encoding [v2]
In-Reply-To: 
References: 
 
Message-ID: <0VYRPZr5WZMV2FcWuBUQ1hXPcvUizP7mRIub1swk1jQ=.19b21b51-37ed-44cc-99d1-37e9b16dfe72@github.com>

On Wed, 16 Apr 2025 03:24:26 GMT, Stuart Marks  wrote:

>> Remove the #ifdef MACOSX from platform-independent System.c, which (on Mac) sets native.encoding from sprops.encoding or (on non-Mac Unix and Windows) sets native.encoding from sprops.sun_jnu_encoding. After this removal, the native.encoding property will be set from sprops.encoding and the sun.jnu.encoding property will be set from sprops.sun_jnu_encoding.
>> 
>> Change the windows java_props_md.c so that it initializes sprops.sun_jnu_encoding and then copies that value to sprops.encoding. Previously, sprops.encoding was initialized with data from other Windows APIs, but this value was ignored by platform-independent code, which was kind of confusing.
>> 
>> There are no changes to the Unix (Mac & non-Mac) platform-specific code. It already has code to set sprops.encoding and sprops.sun_jnu_encoding properly, including macOS-specific code to set the latter to UTF-8 unconditionally.
>> 
>> There should be no behavior changes on any platform.
>> 
>> I changed variable names in windows/java_props_md.c to make it clear that the values stored into them are unused. Of course there are other possibilities here, such as changing the interface to SetupI18nProps(). I'm open to suggestions.
>
> Stuart Marks 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:
> 
>  - Move asserts into platform-independent code.
>  - Merge branch 'master' into JDK-8354464-additional-cleanup-native-encoding
>  - Rename variables to make clear they're not used.
>  - 8354464: Additional cleanup setting up native.encoding

I've gone through this, I don't see any issues.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24607#pullrequestreview-2772512457

From ihse at openjdk.org  Wed Apr 16 13:44:52 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Apr 2025 13:44:52 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 16 Apr 2025 10:35:02 GMT, Matthias Baesken  wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Also document UTF-8 requirements (solves JDK-8338973)
>>  - Let configure only accept utf-8 locales
>>  - Address review comments from Kim
>
> make/autoconf/basic.m4 line 155:
> 
>> 153:       else
>> 154:         AC_MSG_RESULT([no UTF-8 locale found])
>> 155:         AC_MSG_ERROR([No UTF-8 locale found. This is required for building successfully.])
> 
> Seems we run into this 'else' part  on  AIX
> 
> 
> checking for locale to use... no UTF-8 locale found
> configure: error: No UTF-8 locale found. This is required for building successfully.
> configure exiting with result code 1
> 
> maybe it would be nice to display the desired ones C.UTF-8 or en_US.UTF-8 in this message too for more clarity?  (have to check if there are other names on AIX)

If you have a locale named `.UTF-8` as your active locale, that will also be accepted, so it is not limited to C and en_US. But it might be an idea to include it in the error message, yes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24574#discussion_r2046971091

From rriggs at openjdk.org  Wed Apr 16 13:49:38 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 16 Apr 2025 13:49:38 GMT
Subject: RFR: 8354084: Streamline XPath API's extension function control
 [v3]
In-Reply-To: <0y0IinbBL-kjyu8eELDF1VqcJ_s7cChpMss0MNuua2w=.5640dfbf-98c4-44e6-b9f4-053bf8a5fb84@github.com>
References: <2h00m7NTlmM0pu-x7bRU7_UfgKkS2WVJ4jUEF3hnkzo=.a48773d0-d6e6-4505-8511-76902957b9eb@github.com>
 <0y0IinbBL-kjyu8eELDF1VqcJ_s7cChpMss0MNuua2w=.5640dfbf-98c4-44e6-b9f4-053bf8a5fb84@github.com>
Message-ID: 

On Mon, 14 Apr 2025 21:00:22 GMT, Joe Wang  wrote:

>> Streamline the extension function control in the XPath API by relying solely on [XPathFunctionResolver](https://docs.oracle.com/en/java/javase/24/docs/api/java.xml/javax/xml/xpath/XPathFunctionResolver.html), which provides a secure and developer-defined mechanism. Remove the feature FEATURE_SECURE_PROCESSING and jdk.xml.enableExtensionFunctions from the decision path that are redundant with regard to XPath's Extension Functions.
>> 
>> Note the comment in JAXPExtensionsProvider, starting at  "JAXP 1.3 spec says When ...", was not accurate. Refer to the spec: https://docs.oracle.com/en/java/javase/24/docs/api/java.xml/javax/xml/XMLConstants.html#FEATURE_SECURE_PROCESSING, FSP does not have specific requirement for the XPath functions.
>> 
>> Tests:
>>     Tier1 - 3 passed with regard to this change. There were unrelated/known failures (e.g. bug8329757).
>>     JCK passed except the previously reported issue (JCK-7322355).
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rewind resource files, leave them to L10n resource files update

Changes requested by rriggs (Reviewer).

src/java.xml/share/classes/module-info.java line 883:

> 881:  * 
> 882:  *     Transform

> 883:  *     XPath

The additional confirming text in the CSR is not present above.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24605#pullrequestreview-2772604102
PR Review Comment: https://git.openjdk.org/jdk/pull/24605#discussion_r2046981229

From duke at openjdk.org  Wed Apr 16 13:58:18 2025
From: duke at openjdk.org (duke)
Date: Wed, 16 Apr 2025 13:58:18 GMT
Subject: Withdrawn: 8347814: Make all imports consistent in the FFM API tests
 and benchmarks
In-Reply-To: <5KNH2AAZ_KnLt2xRMfHFFNmJ8zf0p6n-arS-XSq5jm8=.3b36aafe-b403-4bf4-89e3-548829d46673@github.com>
References: <5KNH2AAZ_KnLt2xRMfHFFNmJ8zf0p6n-arS-XSq5jm8=.3b36aafe-b403-4bf4-89e3-548829d46673@github.com>
Message-ID: 

On Wed, 19 Feb 2025 09:22:09 GMT, Per Minborg  wrote:

> This PR proposes to make all imports consistent in the FFM API tests and benchmarks.
> 
> This is a follow-up PR from https://github.com/openjdk/jdk/pull/22827
> 
> Passes tier1-3

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/23689

From tpushkin at openjdk.org  Wed Apr 16 14:14:02 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 16 Apr 2025 14:14:02 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v9]
In-Reply-To: 
References: 
Message-ID: 

> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app.
> 
> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible.

Timofei Pushkin has updated the pull request incrementally with two additional commits since the last revision:

 - Implement super overshadowing warning
 - Omit Source classes from archive

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24223/files
  - new: https://git.openjdk.org/jdk/pull/24223/files/fca3c919..26371665

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=07-08

  Stats: 397 lines in 10 files changed: 259 ins; 132 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24223.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223

PR: https://git.openjdk.org/jdk/pull/24223

From tpushkin at openjdk.org  Wed Apr 16 14:34:25 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 16 Apr 2025 14:34:25 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v10]
In-Reply-To: 
References: 
Message-ID: 

> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app.
> 
> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible.

Timofei Pushkin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Empty commit to make GH update the PR
 - Merge remote-tracking branch 'openjdk-jdk/master' into one-loader
 - Implement super overshadowing warning
 - Omit Source classes from archive
 - Remove unused imports
 - Fix indentation
 - Extend ClassFromClasspath test
 - Remove findClass, extend explanation comments
 - Remove unnecessary scoping
 - Don't use URLClassPath
 - ... and 5 more: https://git.openjdk.org/jdk/compare/465c8e65...595756f3

-------------

Changes: https://git.openjdk.org/jdk/pull/24223/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=09
  Stats: 659 lines in 13 files changed: 475 ins; 122 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/24223.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223

PR: https://git.openjdk.org/jdk/pull/24223

From liach at openjdk.org  Wed Apr 16 14:45:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Apr 2025 14:45:46 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: 
References: 
 
 
 <6dAYgfNcUgA3z3iid8wXPNo3qhdhZGDbCgOfbfA0skE=.8194c6ee-81df-4170-a983-0283c2234d0b@github.com>
 
Message-ID: <5VoTSyeoyECVkqefMEk2IRs1y64sXHLvkjM_vRBVUKM=.c8a9d588-d203-4962-9cfd-be867d5d3807@github.com>

On Wed, 16 Apr 2025 10:41:48 GMT, Alan Bateman  wrote:

>> Any quick proposals how to rephrase JavaDocs and CSR? As the CSR is already reviewed I am a bit reluctant to hold the train for this, as IMHO *masses* of classes and interfaces would need such a disclaimer, if we kick-off that ball here...
>
> I think Roger's suggestion is for a different JBS issue / PR / CSR.

Yeah, we already added this API to allow implementations to be more consistent under race condition. So for changing char sequences, this method's default implementation can throw IOOBE, but it is already specified so it is well-behaved even under race (as you can argue a read observed the shorter state of the CS that causes the failure)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2047095624

From rriggs at openjdk.org  Wed Apr 16 14:47:49 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 16 Apr 2025 14:47:49 GMT
Subject: RFR: 8354464: Additional cleanup setting up native.encoding [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 16 Apr 2025 03:24:26 GMT, Stuart Marks  wrote:

>> Remove the #ifdef MACOSX from platform-independent System.c, which (on Mac) sets native.encoding from sprops.encoding or (on non-Mac Unix and Windows) sets native.encoding from sprops.sun_jnu_encoding. After this removal, the native.encoding property will be set from sprops.encoding and the sun.jnu.encoding property will be set from sprops.sun_jnu_encoding.
>> 
>> Change the windows java_props_md.c so that it initializes sprops.sun_jnu_encoding and then copies that value to sprops.encoding. Previously, sprops.encoding was initialized with data from other Windows APIs, but this value was ignored by platform-independent code, which was kind of confusing.
>> 
>> There are no changes to the Unix (Mac & non-Mac) platform-specific code. It already has code to set sprops.encoding and sprops.sun_jnu_encoding properly, including macOS-specific code to set the latter to UTF-8 unconditionally.
>> 
>> There should be no behavior changes on any platform.
>> 
>> I changed variable names in windows/java_props_md.c to make it clear that the values stored into them are unused. Of course there are other possibilities here, such as changing the interface to SetupI18nProps(). I'm open to suggestions.
>
> Stuart Marks 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:
> 
>  - Move asserts into platform-independent code.
>  - Merge branch 'master' into JDK-8354464-additional-cleanup-native-encoding
>  - Rename variables to make clear they're not used.
>  - 8354464: Additional cleanup setting up native.encoding

Changes requested by rriggs (Reviewer).

src/java.base/windows/native/libjava/java_props_md.c line 663:

> 661:                            &sprops.format_country,
> 662:                            &sprops.format_variant,
> 663:                            &format_encoding_unused);

A cleaner change would be to modify SetupI18nProps to remove the encoding argument. 
SetupI18nProps is a file local static function, there are no other uses.
And drop the dummy variables.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24607#pullrequestreview-2772810412
PR Review Comment: https://git.openjdk.org/jdk/pull/24607#discussion_r2047099778

From rriggs at openjdk.org  Wed Apr 16 15:02:45 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 16 Apr 2025 15:02:45 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <5VoTSyeoyECVkqefMEk2IRs1y64sXHLvkjM_vRBVUKM=.c8a9d588-d203-4962-9cfd-be867d5d3807@github.com>
References: 
 
 
 <6dAYgfNcUgA3z3iid8wXPNo3qhdhZGDbCgOfbfA0skE=.8194c6ee-81df-4170-a983-0283c2234d0b@github.com>
 
 <5VoTSyeoyECVkqefMEk2IRs1y64sXHLvkjM_vRBVUKM=.c8a9d588-d203-4962-9cfd-be867d5d3807@github.com>
Message-ID: 

On Wed, 16 Apr 2025 14:42:38 GMT, Chen Liang  wrote:

>> I think Roger's suggestion is for a different JBS issue / PR / CSR.
>
> Yeah, we already added this API to allow implementations to be more consistent under race condition. So for changing char sequences, this method's default implementation can throw IOOBE, but it is already specified so it is well-behaved even under race (as you can argue a read observed the shorter state of the CS that causes the failure)

Omitting it is fine, it was just a reminder that an interface cannot make any definitive statements about its implementations and sometime should warn the unwary user. (We all expect them to adhere to the contract described in each method, but who knows.)
The statement in the implSpec is fine as it only applies to the default implementation, but can be mis-read and thought to apply to all implementations. YMMV.
And though I see consensus, I don't see any approvals yet, including the CSR.
Its good to see it settle down and make progress.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2047135826

From duke at openjdk.org  Wed Apr 16 15:05:12 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 16 Apr 2025 15:05:12 GMT
Subject: RFR: 8077587: BigInteger Roots
Message-ID: 

This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.

-------------

Commit messages:
 - Remove trailing whitespaces
 - Merge branch 'openjdk:master' into BigInteger-nth-root
 - Add nthRoot(int) methods and optimize pow(int)

Changes: https://git.openjdk.org/jdk/pull/24690/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8077587
  Stats: 246 lines in 2 files changed: 207 ins; 16 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From duke at openjdk.org  Wed Apr 16 15:59:10 2025
From: duke at openjdk.org (Johannes Graham)
Date: Wed, 16 Apr 2025 15:59:10 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 15 Apr 2025 22:21:31 GMT, Johannes Graham  wrote:

>> The `DigitList` class used in `DecimalFormat` does not reset the `data` array in its clone method. This can cause interference when clones are used concurrently.
>
> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
> 
>   break after mismatch

I've added a reflection-based test to see how it looks. We could go with either test, or both.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24598#issuecomment-2810025614

From duke at openjdk.org  Wed Apr 16 15:59:10 2025
From: duke at openjdk.org (Johannes Graham)
Date: Wed, 16 Apr 2025 15:59:10 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v7]
In-Reply-To: 
References: 
Message-ID: 

> The `DigitList` class used in `DecimalFormat` does not reset the `data` array in its clone method. This can cause interference when clones are used concurrently.

Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:

  reflective test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24598/files
  - new: https://git.openjdk.org/jdk/pull/24598/files/abda88ef..87e652be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24598&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24598&range=05-06

  Stats: 66 lines in 1 file changed: 64 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24598.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24598/head:pull/24598

PR: https://git.openjdk.org/jdk/pull/24598

From tpushkin at openjdk.org  Wed Apr 16 15:59:54 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Wed, 16 Apr 2025 15:59:54 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 16 Apr 2025 14:34:25 GMT, Timofei Pushkin  wrote:

>> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app.
>> 
>> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible.
>
> Timofei Pushkin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Empty commit to make GH update the PR
>  - Merge remote-tracking branch 'openjdk-jdk/master' into one-loader
>  - Implement super overshadowing warning
>  - Omit Source classes from archive
>  - Remove unused imports
>  - Fix indentation
>  - Extend ClassFromClasspath test
>  - Remove findClass, extend explanation comments
>  - Remove unnecessary scoping
>  - Don't use URLClassPath
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/465c8e65...595756f3

Besides adding the warnings I noticed that `UnregisteredClassLoader` is omitted from the dump and implemented the same for `UnregisteredClassLoader$Source` and its implementations.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24223#issuecomment-2810027521

From liach at openjdk.org  Wed Apr 16 15:59:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Apr 2025 15:59:48 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG  wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'

The implementation looks good. Do you think we need some unit tests for this new API, especially against the default implementation?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2810022443

From duke at openjdk.org  Wed Apr 16 15:59:49 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 16 Apr 2025 15:59:49 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG  wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'

IMHO the existing `Reader.of()` tests do cover all implementations already.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2810027377

From liach at openjdk.org  Wed Apr 16 16:06:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Apr 2025 16:06:59 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG  wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'

Relying on another user is not a good practice - it is possible that we switch `Reader.of` to another implementation. The tests can be as simple as copying the `Reader.of` tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2810046366

From duke at openjdk.org  Wed Apr 16 16:12:57 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 16 Apr 2025 16:12:57 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG  wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'

Nevertheless, the tests are there, so no *new* ones are needed. We can duplicate them, if a majority thinks it is beneficial.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2810057394

From duke at openjdk.org  Wed Apr 16 16:12:58 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 16 Apr 2025 16:12:58 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 16 Apr 2025 16:08:21 GMT, Jaikiran Pai  wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'
>
> src/java.base/share/classes/java/lang/CharSequence.java line 342:
> 
>> 340:      * @since 25
>> 341:      */
>> 342:     public default void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin) {
> 
> Hello Markus, given these new methods on `CharSequence` and the `CharBuffer`, we should add a jtreg test to verify that the default implementation of these methods do work as specified. 
> 
> Edit: I now see Chen too had a similar comment about adding a regression test.

This is already discussed in a separate thread.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2047265794

From jpai at openjdk.org  Wed Apr 16 16:12:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Apr 2025 16:12:58 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG  wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'

src/java.base/share/classes/java/lang/CharSequence.java line 342:

> 340:      * @since 25
> 341:      */
> 342:     public default void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin) {

Hello Markus, given these new methods on `CharSequence` and the `CharBuffer`, we should add a jtreg test to verify that the default implementation of these methods do work as specified. 

Edit: I now see Chen too had a similar comment about adding a regression test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2047263593

From naoto at openjdk.org  Wed Apr 16 16:17:49 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 16 Apr 2025 16:17:49 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 14 Apr 2025 12:53:35 GMT, Magnus Ihse Bursie  wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim

We will probably need to make sure things are ok on Windows as well (they are the other confusing environment)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2810074157

From joehw at openjdk.org  Wed Apr 16 16:22:59 2025
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 16 Apr 2025 16:22:59 GMT
Subject: RFR: 8354084: Streamline XPath API's extension function control
 [v4]
In-Reply-To: <2h00m7NTlmM0pu-x7bRU7_UfgKkS2WVJ4jUEF3hnkzo=.a48773d0-d6e6-4505-8511-76902957b9eb@github.com>
References: <2h00m7NTlmM0pu-x7bRU7_UfgKkS2WVJ4jUEF3hnkzo=.a48773d0-d6e6-4505-8511-76902957b9eb@github.com>
Message-ID: <_fY5AaNMkNSFWth2TKmkd7kKIdWHIZ982zp047JhIlo=.f3348c1f-6d1a-4396-a606-dc4ad7f92e48@github.com>

> Streamline the extension function control in the XPath API by relying solely on [XPathFunctionResolver](https://docs.oracle.com/en/java/javase/24/docs/api/java.xml/javax/xml/xpath/XPathFunctionResolver.html), which provides a secure and developer-defined mechanism. Remove the feature FEATURE_SECURE_PROCESSING and jdk.xml.enableExtensionFunctions from the decision path that are redundant with regard to XPath's Extension Functions.
> 
> Note the comment in JAXPExtensionsProvider, starting at  "JAXP 1.3 spec says When ...", was not accurate. Refer to the spec: https://docs.oracle.com/en/java/javase/24/docs/api/java.xml/javax/xml/XMLConstants.html#FEATURE_SECURE_PROCESSING, FSP does not have specific requirement for the XPath functions.
> 
> Tests:
>     Tier1 - 3 passed with regard to this change. There were unrelated/known failures (e.g. bug8329757).
>     JCK passed except the previously reported issue (JCK-7322355).

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  update javadoc for the jdk.xml.enableExtensionFunctions property

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24605/files
  - new: https://git.openjdk.org/jdk/pull/24605/files/c7ec55a1..4f26a489

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24605&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24605&range=02-03

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24605/head:pull/24605

PR: https://git.openjdk.org/jdk/pull/24605

From joehw at openjdk.org  Wed Apr 16 16:22:59 2025
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 16 Apr 2025 16:22:59 GMT
Subject: RFR: 8354084: Streamline XPath API's extension function control
 [v4]
In-Reply-To: 
References: <2h00m7NTlmM0pu-x7bRU7_UfgKkS2WVJ4jUEF3hnkzo=.a48773d0-d6e6-4505-8511-76902957b9eb@github.com>
 <0y0IinbBL-kjyu8eELDF1VqcJ_s7cChpMss0MNuua2w=.5640dfbf-98c4-44e6-b9f4-053bf8a5fb84@github.com>
 
Message-ID: <1tZP-RchpsBbHjSnQdMu8lQbP_0ewtNkkmvQRn_dLIU=.0303c639-2342-4679-a0a4-026ce022c244@github.com>

On Wed, 16 Apr 2025 13:47:28 GMT, Roger Riggs  wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update javadoc for the jdk.xml.enableExtensionFunctions property
>
> src/java.xml/share/classes/module-info.java line 883:
> 
>> 881:  * 
>> 882:  *     Transform

>> 883:  *     XPath
> 
> The additional confirming text in the CSR is not present above.

Thanks Roger. Updated the description for the jdk.xml.enableExtensionFunctions property and fixed the default value (missing from the JDK-8343001 patch).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24605#discussion_r2047283377

From joehw at openjdk.org  Wed Apr 16 16:26:41 2025
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 16 Apr 2025 16:26:41 GMT
Subject: RFR: 8354084: Streamline XPath API's extension function control
 [v5]
In-Reply-To: <2h00m7NTlmM0pu-x7bRU7_UfgKkS2WVJ4jUEF3hnkzo=.a48773d0-d6e6-4505-8511-76902957b9eb@github.com>
References: <2h00m7NTlmM0pu-x7bRU7_UfgKkS2WVJ4jUEF3hnkzo=.a48773d0-d6e6-4505-8511-76902957b9eb@github.com>
Message-ID: 

> Streamline the extension function control in the XPath API by relying solely on [XPathFunctionResolver](https://docs.oracle.com/en/java/javase/24/docs/api/java.xml/javax/xml/xpath/XPathFunctionResolver.html), which provides a secure and developer-defined mechanism. Remove the feature FEATURE_SECURE_PROCESSING and jdk.xml.enableExtensionFunctions from the decision path that are redundant with regard to XPath's Extension Functions.
> 
> Note the comment in JAXPExtensionsProvider, starting at  "JAXP 1.3 spec says When ...", was not accurate. Refer to the spec: https://docs.oracle.com/en/java/javase/24/docs/api/java.xml/javax/xml/XMLConstants.html#FEATURE_SECURE_PROCESSING, FSP does not have specific requirement for the XPath functions.
> 
> Tests:
>     Tier1 - 3 passed with regard to this change. There were unrelated/known failures (e.g. bug8329757).
>     JCK passed except the previously reported issue (JCK-7322355).

Joe Wang 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 'master' into JDK-8354084
 - update javadoc for the jdk.xml.enableExtensionFunctions property
 - rewind resource files, leave them to L10n resource files update
 - add copyright and docs
 - 8354084: Streamline XPath API's extension function control

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24605/files
  - new: https://git.openjdk.org/jdk/pull/24605/files/4f26a489..8359153c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24605&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24605&range=03-04

  Stats: 179596 lines in 307 files changed: 10747 ins; 168002 del; 847 mod
  Patch: https://git.openjdk.org/jdk/pull/24605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24605/head:pull/24605

PR: https://git.openjdk.org/jdk/pull/24605

From jpai at openjdk.org  Wed Apr 16 16:31:59 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Apr 2025 16:31:59 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG  wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'

> Nevertheless, the tests are there, so no _new_ ones are needed. We can duplicate them, if a majority thinks it is beneficial.

As noted in the contribution guide (https://openjdk.org/guide/#testing-the-jdk), regression tests are expected for a majority of changes that are done in the JDK. There are situations where regressions tests cannot be added, but this isn't one. I believe a new method with a default specified implementation in a public exported interface deserves a regression test of its own.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2810110015

From duke at openjdk.org  Wed Apr 16 16:36:02 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 16 Apr 2025 16:36:02 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 16 Apr 2025 16:29:23 GMT, Jaikiran Pai  wrote:

> > Nevertheless, the tests are there, so no _new_ ones are needed. We can duplicate them, if a majority thinks it is beneficial.
> 
> As noted in the contribution guide (https://openjdk.org/guide/#testing-the-jdk), regression tests are expected for a majority of changes that are done in the JDK. There are situations where regressions tests cannot be added, but this isn't one. I believe a new method with a default specified implementation in a public exported interface deserves a regression test of its own.

The docs do not say that the regression test must be *separate*. Again: We *do have* testing covered. The question is *not* whether we need a test -we *do have one*-, but whether to *duplicate* it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2810119199

From naoto at openjdk.org  Wed Apr 16 16:37:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 16 Apr 2025 16:37:52 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 16 Apr 2025 15:59:10 GMT, Johannes Graham  wrote:

>> The `DigitList` class used in `DecimalFormat` does not reset the `data` array in its clone method. This can cause interference when clones are used concurrently.
>
> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflective test

Thanks for adding the test. Let's keep them both.

test/jdk/java/text/Format/DecimalFormat/CloneTest.java line 56:

> 54: 
> 55:         DIGIT_LIST_CLASS = digitList.getClass();
> 56:     }

I'd add some comment saying that this is a whitebox testing, so it might fail if the internal implementation changes (quite unlikely though). And if accessing digitList/data fails, it should throw `jtreg.SkippedException` instead of a real exception in the actual @test methods.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24598#pullrequestreview-2773165558
PR Review Comment: https://git.openjdk.org/jdk/pull/24598#discussion_r2047318489

From ccheung at openjdk.org  Wed Apr 16 16:47:48 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 16 Apr 2025 16:47:48 GMT
Subject: RFR: 8352001: AOT cache should not contain classes injected into
 built-in class loaders [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 16 Apr 2025 00:51:23 GMT, Ioi Lam  wrote:

>> During an application's training run, it's possible to inject classes into the built-in platform/app class loaders with reflection calls. 
>> 
>> - Before [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), only the names of these classes were recorded in the AOT config file. When the AOT cache is generated, these classes are automatically filtered out.
>> - Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), these classes are stored as parsed InstanceKlasses in the AOT config file, and will be transferred into the AOT cache. This new behavior may cause some applications to fail, as they may inject bytecodes that have environment dependencies.
>> 
>> For safety, this PR filters out such injected classes from the AOT config file.
>
> Ioi Lam 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 'master' into 8352001-exclude-injected-classes-from-builtin-loaders
>  - @calvinccheung review
>  - @matias9927 comment
>  - Merge branch 'master' into 8352001-exclude-injected-classes-from-builtin-loaders
>  - 8352001: AOT cache should not contain classes injected into built-in class loaders

Thanks for the update. Just one minor comment.

src/hotspot/share/cds/aotArtifactFinder.cpp line 26:

> 24: 
> 25: #include "cds/aotClassLinker.hpp"
> 26: #include "cds/aotClassLocation.hpp"

Is this include needed?

-------------

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24046#pullrequestreview-2773195909
PR Review Comment: https://git.openjdk.org/jdk/pull/24046#discussion_r2047335910

From jpai at openjdk.org  Wed Apr 16 16:50:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Apr 2025 16:50:01 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 16 Apr 2025 16:33:29 GMT, Markus KARG  wrote:

>  If duplication is wanted, I will do it. I am just waiting for a majority to clearly say that they want duplication.

By duplication, do you mean copy pasting the `testReadBII(Reader reader)`, `testReadBIILenZero(Reader reader)`, `testReadDirectCharBuffer(Reader reader)` and similar such test methods from the existing `test/jdk/java/io/Reader/Of.java` test class? Including all those references to the `Reader`?

Implementing a test that calls `Reader.of()` to verify the behaviour of an independent `CharSequence.getChars()` method isn't the kind of test I am proposing. It should be possible to just invoke `CharSequence.getChars()` on a `CharSequence` instance to verify that its default method does what it specifies. So these new tests won't be duplicating any existing test code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2810153917

From rriggs at openjdk.org  Wed Apr 16 16:52:56 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 16 Apr 2025 16:52:56 GMT
Subject: RFR: 8354084: Streamline XPath API's extension function control
 [v5]
In-Reply-To: 
References: <2h00m7NTlmM0pu-x7bRU7_UfgKkS2WVJ4jUEF3hnkzo=.a48773d0-d6e6-4505-8511-76902957b9eb@github.com>
 
Message-ID: 

On Wed, 16 Apr 2025 16:26:41 GMT, Joe Wang  wrote:

>> Streamline the extension function control in the XPath API by relying solely on [XPathFunctionResolver](https://docs.oracle.com/en/java/javase/24/docs/api/java.xml/javax/xml/xpath/XPathFunctionResolver.html), which provides a secure and developer-defined mechanism. Remove the feature FEATURE_SECURE_PROCESSING and jdk.xml.enableExtensionFunctions from the decision path that are redundant with regard to XPath's Extension Functions.
>> 
>> Note the comment in JAXPExtensionsProvider, starting at  "JAXP 1.3 spec says When ...", was not accurate. Refer to the spec: https://docs.oracle.com/en/java/javase/24/docs/api/java.xml/javax/xml/XMLConstants.html#FEATURE_SECURE_PROCESSING, FSP does not have specific requirement for the XPath functions.
>> 
>> Tests:
>>     Tier1 - 3 passed with regard to this change. There were unrelated/known failures (e.g. bug8329757).
>>     JCK passed except the previously reported issue (JCK-7322355).
>
> Joe Wang 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 'master' into JDK-8354084
>  - update javadoc for the jdk.xml.enableExtensionFunctions property
>  - rewind resource files, leave them to L10n resource files update
>  - add copyright and docs
>  - 8354084: Streamline XPath API's extension function control

look fine.  Thanks

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24605#pullrequestreview-2773211383

From duke at openjdk.org  Wed Apr 16 17:01:58 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 16 Apr 2025 17:01:58 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Wed, 16 Apr 2025 16:47:33 GMT, Jaikiran Pai  wrote:

>It should be possible to just invoke `CharSequence.getChars()` on a `CharSequence` instance to verify that its default method does what it specifies. So these new tests won't be duplicating any existing test code.

IIUC then you will be fine with a test that **solely** tests *the default implementation* of `CharSequence.getChars()`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2810179689

From jpai at openjdk.org  Wed Apr 16 17:07:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Apr 2025 17:07:01 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: <9BsFYz2RyshIdK1liYcrQdIiJMf5yuhajoVSZ8V5LUQ=.23bc0d84-4f72-41d2-b5d1-753bc12c4e22@github.com>

On Wed, 16 Apr 2025 16:58:50 GMT, Markus KARG  wrote:

> IIUC then you will be fine with a test that solely tests the default implementation of CharSequence.getChars()?

Correct. And a similar separate test for `CharBuffer.getChars()` since that one too is a new default implementation method. I apologize if that wasn't clear in the discussion so far.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2810190843

From iklam at openjdk.org  Wed Apr 16 17:12:07 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Apr 2025 17:12:07 GMT
Subject: RFR: 8352001: AOT cache should not contain classes injected into
 built-in class loaders [v4]
In-Reply-To: 
References: 
Message-ID: 

> During an application's training run, it's possible to inject classes into the built-in platform/app class loaders with reflection calls. 
> 
> - Before [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), only the names of these classes were recorded in the AOT config file. When the AOT cache is generated, these classes are automatically filtered out.
> - Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), these classes are stored as parsed InstanceKlasses in the AOT config file, and will be transferred into the AOT cache. This new behavior may cause some applications to fail, as they may inject bytecodes that have environment dependencies.
> 
> For safety, this PR filters out such injected classes from the AOT config file.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Removed unnecessary include

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24046/files
  - new: https://git.openjdk.org/jdk/pull/24046/files/b5d20c5c..52f53856

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24046&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24046&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24046.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24046/head:pull/24046

PR: https://git.openjdk.org/jdk/pull/24046

From iklam at openjdk.org  Wed Apr 16 17:12:08 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Apr 2025 17:12:08 GMT
Subject: RFR: 8352001: AOT cache should not contain classes injected into
 built-in class loaders [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 16 Apr 2025 16:44:05 GMT, Calvin Cheung  wrote:

>> Ioi Lam 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 'master' into 8352001-exclude-injected-classes-from-builtin-loaders
>>  - @calvinccheung review
>>  - @matias9927 comment
>>  - Merge branch 'master' into 8352001-exclude-injected-classes-from-builtin-loaders
>>  - 8352001: AOT cache should not contain classes injected into built-in class loaders
>
> src/hotspot/share/cds/aotArtifactFinder.cpp line 26:
> 
>> 24: 
>> 25: #include "cds/aotClassLinker.hpp"
>> 26: #include "cds/aotClassLocation.hpp"
> 
> Is this include needed?

I added it by mistake. I've removed it. Could you re-approve?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24046#discussion_r2047374885

From ccheung at openjdk.org  Wed Apr 16 17:19:46 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 16 Apr 2025 17:19:46 GMT
Subject: RFR: 8352001: AOT cache should not contain classes injected into
 built-in class loaders [v4]
In-Reply-To: 
References: 
 
Message-ID: <4WCXfiONTnspvFRxC2DQwC1dPJvTcc6GZZd1D0GXtkQ=.568f3e79-e8c8-4727-b497-38fafb4aa27a@github.com>

On Wed, 16 Apr 2025 17:12:07 GMT, Ioi Lam  wrote:

>> During an application's training run, it's possible to inject classes into the built-in platform/app class loaders with reflection calls. 
>> 
>> - Before [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), only the names of these classes were recorded in the AOT config file. When the AOT cache is generated, these classes are automatically filtered out.
>> - Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), these classes are stored as parsed InstanceKlasses in the AOT config file, and will be transferred into the AOT cache. This new behavior may cause some applications to fail, as they may inject bytecodes that have environment dependencies.
>> 
>> For safety, this PR filters out such injected classes from the AOT config file.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unnecessary include

Marked as reviewed by ccheung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24046#pullrequestreview-2773280416

From bpb at openjdk.org  Wed Apr 16 17:27:47 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 16 Apr 2025 17:27:47 GMT
Subject: RFR: 8354450: Using a File with a path containing a trailing space
 should fail when alternative data streams are disabled (win) [v2]
In-Reply-To: <1EKMYPzdR0EfG8v9_hauG3wPMw0_cRATLZlg0LbE4ps=.049a55bc-797a-4eb4-9b4a-f20b02cafbe4@github.com>
References: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
 
 <1EKMYPzdR0EfG8v9_hauG3wPMw0_cRATLZlg0LbE4ps=.049a55bc-797a-4eb4-9b4a-f20b02cafbe4@github.com>
Message-ID: 

On Wed, 16 Apr 2025 07:33:54 GMT, Alan Bateman  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8354450: Add specific conditional for trailing space; adjust test
>
> src/java.base/windows/classes/java/io/WinNTFileSystem.java line 372:
> 
>> 370:         int len = pathname.length();
>> 371:         if (len > 0 && pathname.charAt(len - 1) == ' ')
>> 372:             return true;
> 
> Can you think about "foo \bar" case too?

I am not sure what you mean here as file paths _can_ contain (s) space(s).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24635#discussion_r2047396907

From bpb at openjdk.org  Wed Apr 16 17:27:48 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 16 Apr 2025 17:27:48 GMT
Subject: RFR: 8354450: Using a File with a path containing a trailing space
 should fail when alternative data streams are disabled (win) [v2]
In-Reply-To: <__CAYO4goU7x0Ee-m-8kgQ-JacRiqXsMPcEJE-hcA1o=.b01de7fd-1214-4cda-a7d8-257ab22f7ae6@github.com>
References: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
 
 <__CAYO4goU7x0Ee-m-8kgQ-JacRiqXsMPcEJE-hcA1o=.b01de7fd-1214-4cda-a7d8-257ab22f7ae6@github.com>
Message-ID: 

On Wed, 16 Apr 2025 09:21:41 GMT, Mikhail Yankelevich  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8354450: Add specific conditional for trailing space; adjust test
>
> test/jdk/java/io/File/WinTrailingSpace.java line 28:
> 
>> 26: 
>> 27: import org.junit.jupiter.api.Test;
>> 28: import static org.junit.jupiter.api.Assertions.*;
> 
> nitpick: wildcard import

I am not fond of wildcard imports either, but it is common practice for static imports like this. I will change it though.

> test/jdk/java/io/File/WinTrailingSpace.java line 61:
> 
>> 59:             f.delete();
>> 60:             f.createNewFile();
>> 61:             assertFalse(f.exists()); // should not reach here
> 
> Do you think this might be easier to debug if there was a message in there rather than an `assertFalse`? In case of an error this will just say failed. However in the failed case where the file wasn't actually created and the error wasn't triggered either it should pass in the current state. This will be more confusing when debugging, especially in case of an intermittent issue.
>  My feeling is that for the long run it might be better to have something like 
> ```java 
> assertFalse("File was created. File exists", f.exists());
> assertEquals("No error thrown", "Error Thrown"); 
> 
> 
> What do you think?

I agree that something like you suggest would be better. I'll take a closer look.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24635#discussion_r2047397807
PR Review Comment: https://git.openjdk.org/jdk/pull/24635#discussion_r2047399125

From duke at openjdk.org  Wed Apr 16 17:36:20 2025
From: duke at openjdk.org (Johannes Graham)
Date: Wed, 16 Apr 2025 17:36:20 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v8]
In-Reply-To: 
References: 
Message-ID: 

> The `DigitList` class used in `DecimalFormat` does not reset the `data` array in its clone method. This can cause interference when clones are used concurrently.

Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:

  use SkippedException if reflective access fails

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24598/files
  - new: https://git.openjdk.org/jdk/pull/24598/files/87e652be..08a32e12

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24598&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24598&range=06-07

  Stats: 77 lines in 1 file changed: 34 ins; 21 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/24598.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24598/head:pull/24598

PR: https://git.openjdk.org/jdk/pull/24598

From duke at openjdk.org  Wed Apr 16 17:37:07 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 16 Apr 2025 17:37:07 GMT
Subject: RFR: 8354424: java/util/logging/LoggingDeadlock5.java fails
 intermittently in tier6 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Increasing timeout for deadlock detection and adjusting for the timeout factor in higher tiers.

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Removing test from the problem list.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24687/files
  - new: https://git.openjdk.org/jdk/pull/24687/files/7dbb696c..3a28b4fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24687&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24687&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24687.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24687/head:pull/24687

PR: https://git.openjdk.org/jdk/pull/24687

From duke at openjdk.org  Wed Apr 16 17:40:39 2025
From: duke at openjdk.org (Johannes Graham)
Date: Wed, 16 Apr 2025 17:40:39 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v9]
In-Reply-To: 
References: 
Message-ID: 

> The `DigitList` class used in `DecimalFormat` does not reset the `data` array in its clone method. This can cause interference when clones are used concurrently.

Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:

  fix catch block

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24598/files
  - new: https://git.openjdk.org/jdk/pull/24598/files/08a32e12..6c23e27e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24598&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24598&range=07-08

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24598.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24598/head:pull/24598

PR: https://git.openjdk.org/jdk/pull/24598

From jlu at openjdk.org  Wed Apr 16 17:45:57 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 16 Apr 2025 17:45:57 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 16 Apr 2025 17:40:39 GMT, Johannes Graham  wrote:

>> The `DigitList` class used in `DecimalFormat` does not reset the `data` array in its clone method. This can cause interference when clones are used concurrently.
>
> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix catch block

Thanks for the changes, the new test looks good to me.

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24598#pullrequestreview-2773350740

From alanb at openjdk.org  Wed Apr 16 17:46:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Apr 2025 17:46:48 GMT
Subject: RFR: 8354450: Using a File with a path containing a trailing space
 should fail when alternative data streams are disabled (win) [v2]
In-Reply-To: 
References: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
 
 <1EKMYPzdR0EfG8v9_hauG3wPMw0_cRATLZlg0LbE4ps=.049a55bc-797a-4eb4-9b4a-f20b02cafbe4@github.com>
 
Message-ID: <7LDV_FtSki03-PTPsSoobe3N-SbtcjVKzf933HBuFoQ=.474914b7-beda-4f80-8655-c0523bd23a87@github.com>

On Wed, 16 Apr 2025 17:23:41 GMT, Brian Burkhalter  wrote:

>> src/java.base/windows/classes/java/io/WinNTFileSystem.java line 372:
>> 
>>> 370:         int len = pathname.length();
>>> 371:         if (len > 0 && pathname.charAt(len - 1) == ' ')
>>> 372:             return true;
>> 
>> Can you think about "foo \bar" case too?
>
> I am not sure what you mean here as file paths _can_ contain (s) space(s).

The question is about directories in the path that end with space. So yes, the file path may contain spaces but the proposed check is only looking at the end last element.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24635#discussion_r2047427427

From smarks at openjdk.org  Wed Apr 16 17:46:48 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 16 Apr 2025 17:46:48 GMT
Subject: RFR: 8354464: Additional cleanup setting up native.encoding [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 16 Apr 2025 14:43:45 GMT, Roger Riggs  wrote:

>> Stuart Marks 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:
>> 
>>  - Move asserts into platform-independent code.
>>  - Merge branch 'master' into JDK-8354464-additional-cleanup-native-encoding
>>  - Rename variables to make clear they're not used.
>>  - 8354464: Additional cleanup setting up native.encoding
>
> src/java.base/windows/native/libjava/java_props_md.c line 663:
> 
>> 661:                            &sprops.format_country,
>> 662:                            &sprops.format_variant,
>> 663:                            &format_encoding_unused);
> 
> A cleaner change would be to modify SetupI18nProps to remove the encoding argument. 
> SetupI18nProps is a file local static function, there are no other uses.
> And drop the dummy variables.

The main focus of this commit is to straighten out the logic between the platform-specific and platform-independent layers.

In the previous state of this file, tracing the origin of the properties on Windows, I ended up following the origin of sprops.encoding all the way through SetupI18nProps, only to find that was ignored entirely at the platform-independent layer. So this change is an improvement in that it clarifies where sprops.encoding comes from, and that SetupI18nProps does some computations that end up being thrown away instead of being stored into a shared data structure that's eventually ignored.

Of course that path is dead code and could be removed without changing the behavior. But this code has a tortured history and it's not entirely clear that it's correct in its current state. In fact @naotoj considered making some changes in this logic [JDK-8352917](https://bugs.openjdk.org/browse/JDK-8352917) but decided against it. However it seems like a possibility that we might revisit this?

Also note that we're now talking about how Windows gets its encoding information from the OS, and not how encoding information is transmitted up through the layers into Java properties, which is the focus of this cleanup.

Anyway I'd like to hear from @naotoj on this. If we're certain the extra stuff in SetupI18nProps is useless, we should clean it up now. But if there might be a use for this information -- maybe stdin.encoding? -- then perhaps it's better to leave it as is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24607#discussion_r2047428294

From iklam at openjdk.org  Wed Apr 16 17:55:55 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Apr 2025 17:55:55 GMT
Subject: RFR: 8352001: AOT cache should not contain classes injected into
 built-in class loaders [v4]
In-Reply-To: <4WCXfiONTnspvFRxC2DQwC1dPJvTcc6GZZd1D0GXtkQ=.568f3e79-e8c8-4727-b497-38fafb4aa27a@github.com>
References: 
 
 <4WCXfiONTnspvFRxC2DQwC1dPJvTcc6GZZd1D0GXtkQ=.568f3e79-e8c8-4727-b497-38fafb4aa27a@github.com>
Message-ID: 

On Wed, 16 Apr 2025 17:16:51 GMT, Calvin Cheung  wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed unnecessary include
>
> Marked as reviewed by ccheung (Reviewer).

Thanks @calvinccheung @calvinccheung for the review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24046#issuecomment-2810293772

From iklam at openjdk.org  Wed Apr 16 17:55:56 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Apr 2025 17:55:56 GMT
Subject: Integrated: 8352001: AOT cache should not contain classes injected
 into built-in class loaders
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 Mar 2025 05:28:47 GMT, Ioi Lam  wrote:

> During an application's training run, it's possible to inject classes into the built-in platform/app class loaders with reflection calls. 
> 
> - Before [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), only the names of these classes were recorded in the AOT config file. When the AOT cache is generated, these classes are automatically filtered out.
> - Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), these classes are stored as parsed InstanceKlasses in the AOT config file, and will be transferred into the AOT cache. This new behavior may cause some applications to fail, as they may inject bytecodes that have environment dependencies.
> 
> For safety, this PR filters out such injected classes from the AOT config file.

This pull request has now been integrated.

Changeset: e433fa27
Author:    Ioi Lam 
URL:       https://git.openjdk.org/jdk/commit/e433fa2719917cff6cb373e9a60981a7418e2f4f
Stats:     246 lines in 11 files changed: 239 ins; 0 del; 7 mod

8352001: AOT cache should not contain classes injected into built-in class loaders

Reviewed-by: ccheung, matsaave

-------------

PR: https://git.openjdk.org/jdk/pull/24046

From clanger at openjdk.org  Wed Apr 16 18:25:38 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 16 Apr 2025 18:25:38 GMT
Subject: RFR: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public [v4]
In-Reply-To: 
References: 
Message-ID: 

> Alternative approach to #24012
> 
> This keeps the current handling of *.pdb vs *.stripped.pdb which allows debugging at the cost of a little hack in jlink. Maybe the code in jlink can be improved, e.g. make it more conditional.
> 
> I'm running this through our testing still to see whether it'll resolve all of the test issues and does not introduce regressions.

Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into JDK-8351842-alternative
 - Merge branch 'master' into JDK-8351842-alternative
 - Merge branch 'master' into JDK-8351842-alternative
 - Extract fix for building debug symbols bundle
 - JDK-8351842

-------------

Changes: https://git.openjdk.org/jdk/pull/24057/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24057&range=03
  Stats: 13 lines in 1 file changed: 12 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24057.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24057/head:pull/24057

PR: https://git.openjdk.org/jdk/pull/24057

From vlivanov at openjdk.org  Wed Apr 16 18:28:52 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 16 Apr 2025 18:28:52 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 16 Apr 2025 02:11:09 GMT, Xiaohong Gong  wrote:

>> Vladimir Ivanov 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 19 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into vector.math.01.java
>>  - RVV and SVE adjustments
>>  - Merge branch 'master' into vector.math.01.java
>>  - Fix windows-aarch64 build failure
>>  - features_string -> cpu_info_string
>>  - Reviews and Float64Vector-related fix
>>  - Misc fixes and cleanups
>>  - CPU features support
>>  - Cleanup
>>  - TODO list
>>  - ... and 9 more: https://git.openjdk.org/jdk/compare/e269cc66...0ffed12f
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 240:
> 
>> 238:                 if (isAARCH64() && vspecies.vectorBitSize() > 128) {
>> 239:                     return false; // FIXME: SVE support only for MAX shapes
>> 240:                 }
> 
> SVE also supports operations for partial vector size, which means the vector size is smaller than MAX size. For example, if the max vector size of a SVE architecture is 512-bit, the FP vector operations with `VectorShape.S_256_BIT` are also supported. They are implemented with the same scalable math functions in SLEEF.
> 
> Hence, I think this check and the assertion in line-198 can be removed. Thanks!

How does it work now? The code in `generate_vector_math_stubs()` in `stubGenerator_aarch64.cpp` only populates `VEC_SIZE_SCALABLE` shapes with SVE versions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2047489059

From vlivanov at openjdk.org  Wed Apr 16 19:21:25 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 16 Apr 2025 19:21:25 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v6]
In-Reply-To: 
References: 
Message-ID: 

> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
> 
> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
> 
> The patch consists of the following parts:
>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
> 
> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
> 
> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
> 
> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
> 
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
> 
> Thanks!

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Fix debugName handling

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24462/files
  - new: https://git.openjdk.org/jdk/pull/24462/files/0ffed12f..84d02cb3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=04-05

  Stats: 45 lines in 4 files changed: 7 ins; 9 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/24462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24462/head:pull/24462

PR: https://git.openjdk.org/jdk/pull/24462

From vlivanov at openjdk.org  Wed Apr 16 19:21:25 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 16 Apr 2025 19:21:25 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: <4q-SatFOWofWAIyxd58Q9O-mJ0C53Y43jKsXCVsdpiY=.a799347a-7399-4d15-9c51-01dc906b5912@github.com>

On Wed, 16 Apr 2025 01:47:02 GMT, Xiaohong Gong  wrote:

>> src/hotspot/share/opto/vectorIntrinsics.cpp line 488:
>> 
>>> 486: // V binaryOp(long address, Class vClass, Class elementType, int length,
>>> 487: //            V v1, V v2,
>>> 488: //            BinaryOperation defaultImpl)
>> 
>> `debugName` parameter is missing
>
> It seems the function should be updated to `libraryBinaryOp` and `libraryUnaryOp`?

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2047597002

From vlivanov at openjdk.org  Wed Apr 16 19:21:28 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 16 Apr 2025 19:21:28 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 16 Apr 2025 00:25:59 GMT, Paul Sandoz  wrote:

>> Vladimir Ivanov 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 19 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into vector.math.01.java
>>  - RVV and SVE adjustments
>>  - Merge branch 'master' into vector.math.01.java
>>  - Fix windows-aarch64 build failure
>>  - features_string -> cpu_info_string
>>  - Reviews and Float64Vector-related fix
>>  - Misc fixes and cleanups
>>  - CPU features support
>>  - Cleanup
>>  - TODO list
>>  - ... and 9 more: https://git.openjdk.org/jdk/compare/b0b76fc4...0ffed12f
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 555:
> 
>> 553: 
>> 554:   const char* debug_name = "";
>> 555:   const TypeInstPtr* debug_name_oop = gvn().type(argument(8))->isa_instptr();
> 
> Should that be:
> 
>   const TypeInstPtr* debug_name_oop = gvn().type(argument(6 + arity))->isa_instptr();
> 
> ?
> Placing the `debugName` parameter before the vector parameters makes it easier to reason about IMO.

Good point. Initially, I intended to keep `debugName` optional, but I don't see why we can't require its presence as other constants. Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2047598327

From vlivanov at openjdk.org  Wed Apr 16 19:29:07 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 16 Apr 2025 19:29:07 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v7]
In-Reply-To: 
References: 
Message-ID: 

> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
> 
> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
> 
> The patch consists of the following parts:
>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
> 
> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
> 
> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
> 
> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
> 
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
> 
> Thanks!

Vladimir Ivanov 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' into vector.math.01.java
 - Fix debugName handling
 - Merge branch 'master' into vector.math.01.java
 - RVV and SVE adjustments
 - Merge branch 'master' into vector.math.01.java
 - Fix windows-aarch64 build failure
 - features_string -> cpu_info_string
 - Reviews and Float64Vector-related fix
 - Misc fixes and cleanups
 - CPU features support
 - ... and 11 more: https://git.openjdk.org/jdk/compare/98dac46a...a288cbbf

-------------

Changes: https://git.openjdk.org/jdk/pull/24462/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=06
  Stats: 1319 lines in 50 files changed: 844 ins; 390 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/24462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24462/head:pull/24462

PR: https://git.openjdk.org/jdk/pull/24462

From naoto at openjdk.org  Wed Apr 16 20:48:46 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 16 Apr 2025 20:48:46 GMT
Subject: RFR: 8354464: Additional cleanup setting up native.encoding [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 16 Apr 2025 17:44:36 GMT, Stuart Marks  wrote:

>> src/java.base/windows/native/libjava/java_props_md.c line 663:
>> 
>>> 661:                            &sprops.format_country,
>>> 662:                            &sprops.format_variant,
>>> 663:                            &format_encoding_unused);
>> 
>> A cleaner change would be to modify SetupI18nProps to remove the encoding argument. 
>> SetupI18nProps is a file local static function, there are no other uses.
>> And drop the dummy variables.
>
> The main focus of this commit is to straighten out the logic between the platform-specific and platform-independent layers.
> 
> In the previous state of this file, tracing the origin of the properties on Windows, I ended up following the origin of sprops.encoding all the way through SetupI18nProps, only to find that was ignored entirely at the platform-independent layer. So this change is an improvement in that it clarifies where sprops.encoding comes from, and that SetupI18nProps does some computations that end up being thrown away instead of being stored into a shared data structure that's eventually ignored.
> 
> Of course that path is dead code and could be removed without changing the behavior. But this code has a tortured history and it's not entirely clear that it's correct in its current state. In fact @naotoj considered making some changes in this logic [JDK-8352917](https://bugs.openjdk.org/browse/JDK-8352917) but decided against it. However it seems like a possibility that we might revisit this?
> 
> Also note that we're now talking about how Windows gets its encoding information from the OS, and not how encoding information is transmitted up through the layers into Java properties, which is the focus of this cleanup.
> 
> Anyway I'd like to hear from @naotoj on this. If we're certain the extra stuff in SetupI18nProps is useless, we should clean it up now. But if there might be a use for this information -- maybe stdin.encoding? -- then perhaps it's better to leave it as is.

I belive they can be removed as they are no where used (and I don't think it will be used for `stdin.encoding` either) So I prefer removing those unused code now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24607#discussion_r2047728357

From naoto at openjdk.org  Wed Apr 16 20:52:46 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 16 Apr 2025 20:52:46 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v9]
In-Reply-To: 
References: 
 
Message-ID: <9Dl1LGem-p2XGNXkV5FWgndFS1SwEd9fvd8kB__u81I=.9b15f38d-f75f-4704-8f65-d24b7ac50efd@github.com>

On Wed, 16 Apr 2025 17:40:39 GMT, Johannes Graham  wrote:

>> The `DigitList` class used in `DecimalFormat` does not reset the `data` array in its clone method. This can cause interference when clones are used concurrently.
>
> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix catch block

Looks good to me. Thanks for fixing this.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24598#pullrequestreview-2773821126

From psandoz at openjdk.org  Wed Apr 16 21:02:58 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 16 Apr 2025 21:02:58 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 16 Apr 2025 19:29:07 GMT, Vladimir Ivanov  wrote:

>> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
>> 
>> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
>> 
>> The patch consists of the following parts:
>>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
>> 
>> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
>> 
>> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
>> 
>> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
>> 
>> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
>> 
>> Thanks!
>
> Vladimir Ivanov 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' into vector.math.01.java
>  - Fix debugName handling
>  - Merge branch 'master' into vector.math.01.java
>  - RVV and SVE adjustments
>  - Merge branch 'master' into vector.math.01.java
>  - Fix windows-aarch64 build failure
>  - features_string -> cpu_info_string
>  - Reviews and Float64Vector-related fix
>  - Misc fixes and cleanups
>  - CPU features support
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/98dac46a...a288cbbf

Very nice work.

I am not too familiar with the format of CPU features on various platforms. Is the regex a best guess effort or something known and/or used by HotSpot too? If the former perhaps we might get tripped up by the assert in `CPUFeatures.validateFeatures` potentially rendering the Vector API unusable. Would it be better instead to drop and debug log?

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24462#pullrequestreview-2773847925

From ccheung at openjdk.org  Wed Apr 16 21:09:23 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 16 Apr 2025 21:09:23 GMT
Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking
Message-ID: 

This RFE allows --add-opens to be specified for AOT cache creation. AOT cache can be used during production run with --add-opens option as long as the same set of options is used during assembly phase.

Passed tiers 1 - 4 testing.

-------------

Commit messages:
 - trailing whitespace
 - 8352003: Support --add-opens with -XX:+AOTClassLinking

Changes: https://git.openjdk.org/jdk/pull/24695/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24695&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352003
  Stats: 169 lines in 5 files changed: 164 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24695.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24695/head:pull/24695

PR: https://git.openjdk.org/jdk/pull/24695

From vlivanov at openjdk.org  Wed Apr 16 21:29:50 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 16 Apr 2025 21:29:50 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v7]
In-Reply-To: 
References: 
 
Message-ID: <8pTnWDaK3Mu9rKPfB079ci42ZFHIQQwZNRMXExwJC_Y=.6199c6f2-505d-4b32-858a-5c7dbd273163@github.com>

On Wed, 16 Apr 2025 19:29:07 GMT, Vladimir Ivanov  wrote:

>> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
>> 
>> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
>> 
>> The patch consists of the following parts:
>>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
>> 
>> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
>> 
>> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
>> 
>> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
>> 
>> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
>> 
>> Thanks!
>
> Vladimir Ivanov 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' into vector.math.01.java
>  - Fix debugName handling
>  - Merge branch 'master' into vector.math.01.java
>  - RVV and SVE adjustments
>  - Merge branch 'master' into vector.math.01.java
>  - Fix windows-aarch64 build failure
>  - features_string -> cpu_info_string
>  - Reviews and Float64Vector-related fix
>  - Misc fixes and cleanups
>  - CPU features support
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/98dac46a...a288cbbf

Both `CPUFeatures.validateFeatures` and the checks it performs are assertions, so it has to be explicitly enabled by `-esa`. The assert validates some assumptions the code has about the format of features string VM produces. And feature names are controlled by JVM (JVM assigns names itself). If there's a mismatch, something is really broken. Why do you think it makes sense to be defensive here and try to recover if the checks fail?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24462#issuecomment-2810842069

From psandoz at openjdk.org  Wed Apr 16 21:46:46 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 16 Apr 2025 21:46:46 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v7]
In-Reply-To: <8pTnWDaK3Mu9rKPfB079ci42ZFHIQQwZNRMXExwJC_Y=.6199c6f2-505d-4b32-858a-5c7dbd273163@github.com>
References: 
 
 <8pTnWDaK3Mu9rKPfB079ci42ZFHIQQwZNRMXExwJC_Y=.6199c6f2-505d-4b32-858a-5c7dbd273163@github.com>
Message-ID: 

On Wed, 16 Apr 2025 21:27:32 GMT, Vladimir Ivanov  wrote:

> Both `CPUFeatures.validateFeatures` and the checks it performs are assertions, so it has to be explicitly enabled by `-esa`. The assert validates some assumptions the code has about the format of features string VM produces. And feature names are controlled by JVM (JVM assigns names itself). If there's a mismatch, something is really broken. Why do you think it makes sense to be defensive here and try to recover if the checks fail?

I was uncertain how the names were produced and if some untested hardware with additional CPU features could trigger an assert. Since as you say they are controlled by the JVM then indeed things are very broken if there is a mismatch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24462#issuecomment-2810882715

From iklam at openjdk.org  Wed Apr 16 21:57:46 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Apr 2025 21:57:46 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 16 Apr 2025 14:34:25 GMT, Timofei Pushkin  wrote:

>> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app.
>> 
>> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible.
>
> Timofei Pushkin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Empty commit to make GH update the PR
>  - Merge remote-tracking branch 'openjdk-jdk/master' into one-loader
>  - Implement super overshadowing warning
>  - Omit Source classes from archive
>  - Remove unused imports
>  - Fix indentation
>  - Extend ClassFromClasspath test
>  - Remove findClass, extend explanation comments
>  - Remove unnecessary scoping
>  - Don't use URLClassPath
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/465c8e65...595756f3

src/hotspot/share/cds/classListParser.cpp line 517:

> 515:     return;
> 516:   }
> 517:   assert(!supertype->is_shared_unregistered_class(), "unregistered supertype cannot be overshadowed");

Does this always prevent an unregistered class to use any other unregistered class as its super type?

I think a better check would be here:


    if (!k->local_interfaces()->contains(specified_interface)) {
+     jio_fprintf(defaultStream::error_stream(), "Specified interface %s (id %d) is not directly implemented\n",
+           specified_interface->external_name(), _interfaces->at(i));
      print_specified_interfaces();
      print_actual_interfaces(k);
+     throw exception .....      
-     error("Specified interface %s (id %d) is not directly implemented",
-           specified_interface->external_name(), _interfaces->at(i));
      }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2047820496

From duke at openjdk.org  Wed Apr 16 22:05:34 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 16 Apr 2025 22:05:34 GMT
Subject: RFR: 8077587: BigInteger Roots [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Correct loop recurrence according to proof of convergence

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/a3f14892..d280c370

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=00-01

  Stats: 11 lines in 1 file changed: 7 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From duke at openjdk.org  Wed Apr 16 22:11:43 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 16 Apr 2025 22:11:43 GMT
Subject: RFR: 8077587: BigInteger Roots [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 16 Apr 2025 22:05:34 GMT, fabioromano1  wrote:

>> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
>> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct loop recurrence according to proof of convergence

@rgiulietti In this PR I've implemented nth root for BigIntegers using Newton's method and optimized BigInteger.pow(int) method. I've also uploaded a proof of convergence for the recurrence used to compute nth root.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2810926459

From jlu at openjdk.org  Wed Apr 16 23:11:15 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 16 Apr 2025 23:11:15 GMT
Subject: RFR: 8354344: Test behavior after cut-over for future ISO 4217
 currency
Message-ID: 

Please review this PR which improves the _ValidateISO4217_ Currency test by adding testing of future currencies after the transition date.

This is done by creating a patched version of Currency that replaces `System.currentTimeMillis()` calls with a mocked value equivalent to `Long.MAX_VALUE`. A module patch is then applied to supply the new Currency class files.

As the test tracks the ISO 4217 data, manual testing of this change can be done by modifying the cut-over year from 2025 to 2026 for the `CW=ANG;2025-04-01-04-00-00;XCG` entry for both the JDK and test data.

Doing so results in behavior such as,
1st test - CW returns the currency ANG.
2nd test - CW returns the currency XCG.

-------------

Commit messages:
 - shorten the ClassFile logic
 - init

Changes: https://git.openjdk.org/jdk/pull/24701/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24701&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354344
  Stats: 92 lines in 1 file changed: 87 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24701.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24701/head:pull/24701

PR: https://git.openjdk.org/jdk/pull/24701

From jiangli at openjdk.org  Wed Apr 16 23:47:15 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 16 Apr 2025 23:47:15 GMT
Subject: RFR: 8354898: jdk/internal/loader/NativeLibraries/Main.java fails on
 static JDK
Message-ID: 

Please review this simple test change that skips the test case loading using JDK `libzip.so` on static JDK in test/jdk/jdk/internal/loader/NativeLibraries/Main.java. AFAICT, the test case using `NativeLibrariesTest.LIB_NAME` (`libnativeLibrariesTest.so`) can provide coverage on static JDK.

Thanks

-------------

Commit messages:
 - Skip testing using JDK libzip.so on static JDK.

Changes: https://git.openjdk.org/jdk/pull/24704/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24704&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354898
  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24704.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24704/head:pull/24704

PR: https://git.openjdk.org/jdk/pull/24704

From naoto at openjdk.org  Thu Apr 17 00:18:42 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 17 Apr 2025 00:18:42 GMT
Subject: RFR: 8354344: Test behavior after cut-over for future ISO 4217
 currency
In-Reply-To: 
References: 
Message-ID: 

On Wed, 16 Apr 2025 23:06:19 GMT, Justin Lu  wrote:

> As the test tracks the ISO 4217 data, manual testing of this change can be done by modifying the cut-over year from 2025 to 2026 for the `CW=ANG;2025-04-01-04-00-00;XCG` entry for both the JDK and test data.

Would it be possible to use `currency.properties` file to provide a test transition, and use this logic test the validity, so that it is not a manual testing? Still it is not 100% same with the data from `currency.data`, but at least provides the transition logic validity, possibly for both simple and special currencies.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24701#issuecomment-2811294606

From smarks at openjdk.org  Thu Apr 17 00:30:00 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 17 Apr 2025 00:30:00 GMT
Subject: RFR: 8354464: Additional cleanup setting up native.encoding [v3]
In-Reply-To: 
References: 
Message-ID: 

> Remove the #ifdef MACOSX from platform-independent System.c, which (on Mac) sets native.encoding from sprops.encoding or (on non-Mac Unix and Windows) sets native.encoding from sprops.sun_jnu_encoding. After this removal, the native.encoding property will be set from sprops.encoding and the sun.jnu.encoding property will be set from sprops.sun_jnu_encoding.
> 
> Change the windows java_props_md.c so that it initializes sprops.sun_jnu_encoding and then copies that value to sprops.encoding. Previously, sprops.encoding was initialized with data from other Windows APIs, but this value was ignored by platform-independent code, which was kind of confusing.
> 
> There are no changes to the Unix (Mac & non-Mac) platform-specific code. It already has code to set sprops.encoding and sprops.sun_jnu_encoding properly, including macOS-specific code to set the latter to UTF-8 unconditionally.
> 
> There should be no behavior changes on any platform.
> 
> I changed variable names in windows/java_props_md.c to make it clear that the values stored into them are unused. Of course there are other possibilities here, such as changing the interface to SetupI18nProps(). I'm open to suggestions.

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Remove encoding parameter from SetupI18nProps.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24607/files
  - new: https://git.openjdk.org/jdk/pull/24607/files/37cd3ed2..d1ba2505

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24607&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24607&range=01-02

  Stats: 17 lines in 1 file changed: 0 ins; 9 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/24607.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24607/head:pull/24607

PR: https://git.openjdk.org/jdk/pull/24607

From smarks at openjdk.org  Thu Apr 17 00:30:00 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 17 Apr 2025 00:30:00 GMT
Subject: RFR: 8354464: Additional cleanup setting up native.encoding [v2]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Wed, 16 Apr 2025 20:46:04 GMT, Naoto Sato  wrote:

>> The main focus of this commit is to straighten out the logic between the platform-specific and platform-independent layers.
>> 
>> In the previous state of this file, tracing the origin of the properties on Windows, I ended up following the origin of sprops.encoding all the way through SetupI18nProps, only to find that was ignored entirely at the platform-independent layer. So this change is an improvement in that it clarifies where sprops.encoding comes from, and that SetupI18nProps does some computations that end up being thrown away instead of being stored into a shared data structure that's eventually ignored.
>> 
>> Of course that path is dead code and could be removed without changing the behavior. But this code has a tortured history and it's not entirely clear that it's correct in its current state. In fact @naotoj considered making some changes in this logic [JDK-8352917](https://bugs.openjdk.org/browse/JDK-8352917) but decided against it. However it seems like a possibility that we might revisit this?
>> 
>> Also note that we're now talking about how Windows gets its encoding information from the OS, and not how encoding information is transmitted up through the layers into Java properties, which is the focus of this cleanup.
>> 
>> Anyway I'd like to hear from @naotoj on this. If we're certain the extra stuff in SetupI18nProps is useless, we should clean it up now. But if there might be a use for this information -- maybe stdin.encoding? -- then perhaps it's better to leave it as is.
>
> I belive they can be removed as they are no where used (and I don't think it will be used for `stdin.encoding` either) So I prefer removing those unused code now.

OK, I've done so. Now testing on Windows....

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24607#discussion_r2047986885

From lmesnik at openjdk.org  Thu Apr 17 00:53:00 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 17 Apr 2025 00:53:00 GMT
Subject: RFR: 8353214: Add testing with --enable-preview
Message-ID: <-PL85c8ObM1KN0uVIMTglhh6apK6fWXHFO_XdbE0UWI=.589ff6c6-b65a-48c8-807a-1960d72cac09@github.com>

Added problemlists and and requires for execution tests with --enable-preview.

The --enable-preview features might significantly change VM/JDK behavior and sometimes it is useful to run tests with preview features enabled. Eventually preview features should be made default and it is expected that all tests should still work. 

The tests that are not compatible with --enable-preview, usually because of compilation mode are marked with corresponding requires tag.

-------------

Commit messages:
 - 8353214: Add testing with --enable-preview

Changes: https://git.openjdk.org/jdk/pull/24706/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24706&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353214
  Stats: 69 lines in 4 files changed: 69 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24706/head:pull/24706

PR: https://git.openjdk.org/jdk/pull/24706

From vlivanov at openjdk.org  Thu Apr 17 01:07:39 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 17 Apr 2025 01:07:39 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v8]
In-Reply-To: 
References: 
Message-ID: 

> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
> 
> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
> 
> The patch consists of the following parts:
>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
> 
> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
> 
> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
> 
> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
> 
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
> 
> Thanks!

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  fix broken merge

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24462/files
  - new: https://git.openjdk.org/jdk/pull/24462/files/a288cbbf..1ade1ffd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24462/head:pull/24462

PR: https://git.openjdk.org/jdk/pull/24462

From xgong at openjdk.org  Thu Apr 17 01:39:41 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 17 Apr 2025 01:39:41 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 16 Apr 2025 18:26:18 GMT, Vladimir Ivanov  wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 240:
>> 
>>> 238:                 if (isAARCH64() && vspecies.vectorBitSize() > 128) {
>>> 239:                     return false; // FIXME: SVE support only for MAX shapes
>>> 240:                 }
>> 
>> SVE also supports operations for partial vector size, which means the vector size is smaller than MAX size. For example, if the max vector size of a SVE architecture is 512-bit, the FP vector operations with `VectorShape.S_256_BIT` are also supported. They are implemented with the same scalable math functions in SLEEF.
>> 
>> Hence, I think this check and the assertion in line-198 can be removed. Thanks!
>
> How does it work now? The code in `generate_vector_math_stubs()` in `stubGenerator_aarch64.cpp` only populates `VEC_SIZE_SCALABLE` shapes with SVE versions.

Please see the `addr` definition code in https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/vectorIntrinsics.cpp#L1877 . If queried `addr` returns `nullptr` for 256-bit vectors, and the arch supports scalable vector, then the `addr` will be assigned to the scalable ones.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2048052819

From xgong at openjdk.org  Thu Apr 17 01:44:45 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 17 Apr 2025 01:44:45 GMT
Subject: RFR: 8351623: VectorAPI: Refactor subword gather load and add SVE
 implementation
In-Reply-To: 
References: 
Message-ID: 

On Wed, 16 Apr 2025 08:58:34 GMT, Xiaohong Gong  wrote:

> ### Summary:
> [JDK-8318650](http://java-service.client.nvidia.com/?q=8318650) added the hotspot intrinsifying of subword gather load APIs for X86 platforms [1]. This patch aims at implementing the equivalent functionality for AArch64 SVE platform. In addition to the AArch64 backend support, this patch also refactors the API implementation in Java side and the compiler mid-end part to make the operations more efficient and maintainable across different architectures.
> 
> ### Background:
> Vector gather load APIs load values from memory addresses calculated by adding a base pointer to integer indices stored in an int array. SVE provides native vector gather load instructions for byte/short types using an int vector saving indices (see [2][3]).
> 
> The number of loaded elements must match the index vector's element count. Since int elements are 4/2 times larger than byte/short elements, and given `MaxVectorSize` constraints, the operation may need to be splitted into multiple parts.
> 
> Using a 128-bit byte vector gather load as an example, there are four scenarios with different `MaxVectorSize`:
> 
> 1. `MaxVectorSize = 16, byte_vector_size = 16`:
>    - Can load 4 indices per vector register
>    - So can finish 4 bytes per gather-load operation
>    - Requires 4 times of gather-loads and final merge
>    Example:
>    ```
>    byte[] arr = [a, b, c, d, e, f, g, h, i, g, k, l, m, n, o, p, ...]
>    int[] idx = [3, 2, 4, 1, 5, 7, 5, 2, 0, 6, 7, 1, 15, 10, 11, 9]
> 
>    4 gather-load:
>    idx_v1 = [1 4 2 3]    gather_v1 = [0000 0000 0000 becd]
>    idx_v2 = [2 5 7 5]    gather_v2 = [0000 0000 0000 cfhf]
>    idx_v3 = [1 7 6 0]    gather_v3 = [0000 0000 0000 bhga]
>    idx_v4 = [9 11 10 15] gather_v4 = [0000 0000 0000 jlkp]
>    merge: v = [jlkp bhga cfhf becd]
>    ```
> 
> 2. `MaxVectorSize = 32, byte_vector_size = MaxVectorSize / 2`:
>    - Can load 8 indices per vector register
>    - So can finish 8 bytes per gather-load operation
>    - Requires 2 times of gather-loads and merge
>    Example:
>    ```
>    byte[] arr = [a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, ...]
>    int[] index = [3, 2, 4, 1, 5, 7, 5, 2, 0, 6, 7, 1, 15, 10, 11, 9]
> 
>    2 gather-load:
>    idx_v1 = [2 5 7 5 1 4 2 3]
>    idx_v2 = [9 11 10 15 1 7 6 0]
>    gather_v1 = [0000 0000 0000 0000 0000 0000 cfhf becd]
>    gather_v2 = [0000 0000 0000 0000 0000 0000 jlkp bhga]
>    merge: v = [0000 0000 0000 0000 jlkp bhga cfhf becd]
>    ```
> 
> 3. `MaxVectorSize = 64, byte_vector_size = MaxVectorSize / 4`:
>    - Can load 16 indices per vector register
>    - So can ...

Hi @jatin-bhateja , could you please help take a look at this PR especially the X86 part? Thanks a lot!
Hi @RealFYang , could you please help review the RVV part? Thanks a lot!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24679#issuecomment-2811506961

From duke at openjdk.org  Thu Apr 17 02:03:43 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 17 Apr 2025 02:03:43 GMT
Subject: RFR: 8077587: BigInteger Roots [v3]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Correct initial estimate of nth root for BigIntegers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/d280c370..91c3d1a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=01-02

  Stats: 17 lines in 1 file changed: 9 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From duke at openjdk.org  Thu Apr 17 02:07:28 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 17 Apr 2025 02:07:28 GMT
Subject: RFR: 8077587: BigInteger Roots [v4]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Removed trailing whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/91c3d1a9..1cfb7751

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From duke at openjdk.org  Thu Apr 17 02:34:46 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 17 Apr 2025 02:34:46 GMT
Subject: RFR: 8077587: BigInteger Roots [v5]
In-Reply-To: 
References: 
Message-ID: <2vjPJdHoZLl4rxFkAHS7gQ9TyWLxGPzEj4HQdobVj9o=.31fa5acd-47c8-4025-845f-610e3db93f48@github.com>

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'BigInteger-nth-root' of https://github.com/fabioromano1/jdk into BigInteger-nth-root
 - Avoid an overflow in computing nth root estimate

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/1cfb7751..9c32ce47

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=03-04

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From duke at openjdk.org  Thu Apr 17 03:13:05 2025
From: duke at openjdk.org (Nicole Xu)
Date: Thu, 17 Apr 2025 03:13:05 GMT
Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class
 jdk.internal.misc.Unsafe [v3]
In-Reply-To: 
References: 
Message-ID: <-dgbT79T1CnPA-bEUUZHoL5mhVErHBIxs9PME_KwwU4=.15b82347-eb63-400f-a8ce-020686c15f94@github.com>

> The UnsafeOps JMH benchmark fails with the following error:
> 
>       ```
>       java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
>       ```
> 
> Since this micro-benchmark is created for `sun.misc.Unsafe` rather than
> `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744.
> 
> Note that even it will raise "proprietary API" warnings after this
> patch, it is acceptable because the relevant APIs are bound for removal
> for the integrity of the platform.

Nicole Xu 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 remote-tracking branch 'upstream/master' into JDK-8349944-add-args
   
   Change-Id: Ib60ccfc5d411f095d1c2fe6e8154a44529e84631
 - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe
   
   The UnsafeOps JMH benchmark fails with the following error:
   
         ```
         java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
         ```
   
   Since this micro-benchmark is created for `sun.misc.Unsafe` rather than
   `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744.
   
   Note that even it will raise "proprietary API" warnings after this
   patch, it is acceptable because the relevant APIs are bound for removal
   for the integrity of the platform.
   
   Change-Id: Ia7c57c2ca09af4b2b3c6cc10ef4ae5a9f3c38a4c
 - Revert "8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe"
   
   This reverts commit ebc32ae2c6e448075fedbdbb2b4879c43829c44b.
 - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe
   
   The UnsafeOps JMH benchmark fails with the following error:
   
         ```
         java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
         ```
   
   To resolve this, we add the required `--add-opens` flag to grant access
   for the benchmark.
   
   Change-Id: I30de213daa9160ee872a4364eb332dcd1636a9ac

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23686/files
  - new: https://git.openjdk.org/jdk/pull/23686/files/b2bbc24e..db7af981

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23686&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23686&range=01-02

  Stats: 414978 lines in 5199 files changed: 120320 ins; 266094 del; 28564 mod
  Patch: https://git.openjdk.org/jdk/pull/23686.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23686/head:pull/23686

PR: https://git.openjdk.org/jdk/pull/23686

From haosun at openjdk.org  Thu Apr 17 03:39:56 2025
From: haosun at openjdk.org (Hao Sun)
Date: Thu, 17 Apr 2025 03:39:56 GMT
Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class
 jdk.internal.misc.Unsafe [v3]
In-Reply-To: <-dgbT79T1CnPA-bEUUZHoL5mhVErHBIxs9PME_KwwU4=.15b82347-eb63-400f-a8ce-020686c15f94@github.com>
References: 
 <-dgbT79T1CnPA-bEUUZHoL5mhVErHBIxs9PME_KwwU4=.15b82347-eb63-400f-a8ce-020686c15f94@github.com>
Message-ID: 

On Thu, 17 Apr 2025 03:13:05 GMT, Nicole Xu  wrote:

>> The UnsafeOps JMH benchmark fails with the following error:
>> 
>>       ```
>>       java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
>>       ```
>> 
>> Since this micro-benchmark is created for `sun.misc.Unsafe` rather than
>> `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744.
>> 
>> Note that even it will raise "proprietary API" warnings after this
>> patch, it is acceptable because the relevant APIs are bound for removal
>> for the integrity of the platform.
>
> Nicole Xu 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 remote-tracking branch 'upstream/master' into JDK-8349944-add-args
>    
>    Change-Id: Ib60ccfc5d411f095d1c2fe6e8154a44529e84631
>  - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe
>    
>    The UnsafeOps JMH benchmark fails with the following error:
>    
>          ```
>          java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
>          ```
>    
>    Since this micro-benchmark is created for `sun.misc.Unsafe` rather than
>    `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744.
>    
>    Note that even it will raise "proprietary API" warnings after this
>    patch, it is acceptable because the relevant APIs are bound for removal
>    for the integrity of the platform.
>    
>    Change-Id: Ia7c57c2ca09af4b2b3c6cc10ef4ae5a9f3c38a4c
>  - Revert "8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe"
>    
>    This reverts commit ebc32ae2c6e448075fedbdbb2b4879c43829c44b.
>  - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe
>    
>    The UnsafeOps JMH benchmark fails with the following error:
>    
>          ```
>          java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
>          ```
>    
>    To resolve this, we add the required `--add-opens` flag to grant access
>    for the benchmark.
>    
>    Change-Id: I30de213daa9160ee872a4364eb332dcd1636a9ac

>>>@AlanBateman Can you review this if this patch looks good in principle?
>>
>> It needs confirmation that it doesn't break the build, I haven't looked into which parts of Liam's change weren't backed out. So if there are no build issues then it should be okay to integrate.
>
> All of the functional changes from JDK-8331081 and the redo got backed out, the only thing that stayed was test coverage, so I wouldn't expect this to break anything today.

Yes. This PR doesn't break the build today as I tested locally.

As for the build failure as mentioned by @cushon , I can reproduce the build failure in my local environment.
1. how to reproduce the failure
It's important to note that we must revert the commit [1ab1c1d](https://github.com/openjdk/jdk/commit/1ab1c1d53b86228be85aac96fa5d69db39ac6317) firstly in order to reproduce the build failure.

the code: this PR with commit 1ab1c1d reverted
create the JMH bundle
configure with --with-jmh=path/to/the/jmh/jar
make images
make test-image # <--- we encounter build error here

2. possible way to mitigate the failure
As mentioned by @xyyNicole , new configure option `--disable-java-warnings-as-errors` is introduced recently in [7aeaa3c](https://github.com/openjdk/jdk/commit/7aeaa3c21c1420191fe8ff59e4cf99eae830754d). As I checked locally, the build failure is gone if we add this option.


the code: this PR with commit 1ab1c1d reverted
create the JMH bundle
configure with --with-jmh=path/to/the/jmh/jar --disable-java-warnings-as-errors
make images
make test-image # <--- no build error now


To be honest, I didn't fully understand [JDK-8349846](https://bugs.openjdk.org/browse/JDK-8349846). I was wondering if `--disable-java-warnings-as-errors` could help to address your concern about this PR. @cushon 

Here is my understanding for this PR:
1. As mentioned by @AlanBateman , "this micro was created for sun.misc.Unsafe, not jdk.internal.misc.Unsafe". We should keep this test intention as it was.
2. This PR doesn't break the build today.
3. As for the build error as mentioned by @cushon, it would be nice if `--disable-java-warnings-as-errors` can mitigate the error. If not, I agree with @liach that it's a different thing and out of the scope of this PR and we should handle it in a separate task.

-------------

Marked as reviewed by haosun (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23686#pullrequestreview-2774494500

From cushon at openjdk.org  Thu Apr 17 04:25:46 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 17 Apr 2025 04:25:46 GMT
Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class
 jdk.internal.misc.Unsafe [v3]
In-Reply-To: 
References: 
 <-dgbT79T1CnPA-bEUUZHoL5mhVErHBIxs9PME_KwwU4=.15b82347-eb63-400f-a8ce-020686c15f94@github.com>
 
Message-ID: 

On Thu, 17 Apr 2025 03:37:03 GMT, Hao Sun  wrote:

> I was wondering if `--disable-java-warnings-as-errors` could help to address your concern about this PR.

It doesn't address the issue unless it's configured by default, which I don't think is being proposed. I think the best approach would be to disable `-Werror` for specific compilations that are using `sun.misc` APIs, instead of disabling it for the entire build using `--disable-java-warnings-as-errors`. You can also proceed with this as-is and revisit if JDK-8349846 happens, I think it's up to you and the reviewers.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2811699055

From liach at openjdk.org  Thu Apr 17 05:06:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Apr 2025 05:06:56 GMT
Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class
 jdk.internal.misc.Unsafe [v3]
In-Reply-To: <-dgbT79T1CnPA-bEUUZHoL5mhVErHBIxs9PME_KwwU4=.15b82347-eb63-400f-a8ce-020686c15f94@github.com>
References: 
 <-dgbT79T1CnPA-bEUUZHoL5mhVErHBIxs9PME_KwwU4=.15b82347-eb63-400f-a8ce-020686c15f94@github.com>
Message-ID: 

On Thu, 17 Apr 2025 03:13:05 GMT, Nicole Xu  wrote:

>> The UnsafeOps JMH benchmark fails with the following error:
>> 
>>       ```
>>       java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
>>       ```
>> 
>> Since this micro-benchmark is created for `sun.misc.Unsafe` rather than
>> `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744.
>> 
>> Note that even it will raise "proprietary API" warnings after this
>> patch, it is acceptable because the relevant APIs are bound for removal
>> for the integrity of the platform.
>
> Nicole Xu 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 remote-tracking branch 'upstream/master' into JDK-8349944-add-args
>    
>    Change-Id: Ib60ccfc5d411f095d1c2fe6e8154a44529e84631
>  - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe
>    
>    The UnsafeOps JMH benchmark fails with the following error:
>    
>          ```
>          java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
>          ```
>    
>    Since this micro-benchmark is created for `sun.misc.Unsafe` rather than
>    `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744.
>    
>    Note that even it will raise "proprietary API" warnings after this
>    patch, it is acceptable because the relevant APIs are bound for removal
>    for the integrity of the platform.
>    
>    Change-Id: Ia7c57c2ca09af4b2b3c6cc10ef4ae5a9f3c38a4c
>  - Revert "8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe"
>    
>    This reverts commit ebc32ae2c6e448075fedbdbb2b4879c43829c44b.
>  - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe
>    
>    The UnsafeOps JMH benchmark fails with the following error:
>    
>          ```
>          java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
>          ```
>    
>    To resolve this, we add the required `--add-opens` flag to grant access
>    for the benchmark.
>    
>    Change-Id: I30de213daa9160ee872a4364eb332dcd1636a9ac

I have crafted a small build patch to allow benchmarks to build with all warnings not causing compilation failures. This is already the behavior for jtreg tests.


diff --git a/make/common/JavaCompilation.gmk b/make/common/JavaCompilation.gmk
index 70b3557baea..7e01e175406 100644
--- a/make/common/JavaCompilation.gmk
+++ b/make/common/JavaCompilation.gmk
@@ -271,7 +271,9 @@ define SetupJavaCompilationBody
   $1_FLAGS += $$($1_JAVAC_FLAGS)

   ifeq ($$(JAVA_WARNINGS_AS_ERRORS), true)
-    $1_FLAGS += -Werror
+    ifeq ($$($1_MUTE_ALL_JAVA_WARNINGS), )
+      $1_FLAGS += -Werror
+    endif
   endif

   ifneq ($$($1_DISABLED_WARNINGS), )
diff --git a/make/test/BuildMicrobenchmark.gmk b/make/test/BuildMicrobenchmark.gmk
index 92f40472c3c..d66b6a357c5 100644
--- a/make/test/BuildMicrobenchmark.gmk
+++ b/make/test/BuildMicrobenchmark.gmk
@@ -87,6 +87,7 @@ $(eval $(call SetupJavaCompilation, BUILD_JDK_MICROBENCHMARK, \
         serial preview dangling-doc-comments, \
     SRC := $(MICROBENCHMARK_SRC), \
     BIN := $(MICROBENCHMARK_CLASSES), \
+    MUTE_ALL_JAVA_WARNINGS := true, \
     JAVAC_FLAGS := \
         --add-exports java.base/jdk.internal.classfile.components=ALL-UNNAMED \
         --add-exports java.base/jdk.internal.classfile.impl=ALL-UNNAMED \


Feel free to take this patch and try building and running on latest mainline.

If you use this patch, please add me as a contributor and add this patch to the build list, like

> /contributor add liach
> /label add build

And make sure other engineers agree with this approach before integrating.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2811752056

From liach at openjdk.org  Thu Apr 17 05:08:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Apr 2025 05:08:44 GMT
Subject: RFR: 8353214: Add testing with --enable-preview
In-Reply-To: <-PL85c8ObM1KN0uVIMTglhh6apK6fWXHFO_XdbE0UWI=.589ff6c6-b65a-48c8-807a-1960d72cac09@github.com>
References: <-PL85c8ObM1KN0uVIMTglhh6apK6fWXHFO_XdbE0UWI=.589ff6c6-b65a-48c8-807a-1960d72cac09@github.com>
Message-ID: 

On Thu, 17 Apr 2025 00:24:50 GMT, Leonid Mesnik  wrote:

> Added problemlists and and requires for execution tests with --enable-preview.
> 
> The --enable-preview features might significantly change VM/JDK behavior and sometimes it is useful to run tests with preview features enabled. Eventually preview features should be made default and it is expected that all tests should still work. 
> 
> The tests that are not compatible with --enable-preview, usually because of compilation mode are marked with corresponding requires tag.

Just curious, which tiers have you run with forced `--enable-preview` and discovered such incompatible tests?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24706#issuecomment-2811755132

From ccheung at openjdk.org  Thu Apr 17 05:44:57 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 17 Apr 2025 05:44:57 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v8]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 16 Apr 2025 07:50:00 GMT, Timofei Pushkin  wrote:

>> src/java.base/share/classes/jdk/internal/misc/CDS.java line 390:
>> 
>>> 388:             @Override
>>> 389:             public byte[] readClassFile(String className) throws IOException {
>>> 390:                 final var subPath = className.replace('.', File.separatorChar).concat(".class");
>> 
>> Should File.separatorChar be ?/? ? (just like at line 369)
>
> No, this is an intentional difference.
> 
> Here the string is then passed to `Path.of(...)` so it should definitely be `File.separatorChar` because this is what `Path.of(...)` expects.
> 
> Regarding line 369, the string is then passed to `JarFile.getEntry(String name)` ? I wasn't able to find the description of the format of the `name` parameter so I followed the way `URLClassLoader` does it, it uses `/` for loading from a JAR (and `File.separatorChar` for loading from a directory). This seems logical since JAR format is platform-independent.

Thanks for the explanation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2048268934

From ccheung at openjdk.org  Thu Apr 17 05:49:45 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 17 Apr 2025 05:49:45 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 16 Apr 2025 14:34:25 GMT, Timofei Pushkin  wrote:

>> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app.
>> 
>> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible.
>
> Timofei Pushkin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Empty commit to make GH update the PR
>  - Merge remote-tracking branch 'openjdk-jdk/master' into one-loader
>  - Implement super overshadowing warning
>  - Omit Source classes from archive
>  - Remove unused imports
>  - Fix indentation
>  - Extend ClassFromClasspath test
>  - Remove findClass, extend explanation comments
>  - Remove unnecessary scoping
>  - Don't use URLClassPath
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/465c8e65...595756f3

Found an issue on the RegUnregSuperTest.java.

test/hotspot/jtreg/runtime/cds/appcds/customLoader/RegUnregSuperTest.java line 77:

> 75:             out.shouldContain("CustomLoadee3Child (id 3) has super-type CustomLoadee3 (id 1) overshadowed by another class with the same name");
> 76:         } else {
> 77:             out.shouldContain("unreg CustomLoadee3Child\n");

Could you remove the linefeed ('\n') chars?
I'm seeing test failure when running with the `-XX:+AOTClassLinking` option.


java.lang.RuntimeException: 'app   CustomLoadee3
' missing from stdout/stderr
	at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253)
	at RegUnregSuperTest.main(RegUnregSuperTest.java:71)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
	at java.base/java.lang.Thread.run(Thread.java:1447)

The expected output is there:
`[1.686s][debug  ][cds,class] klasses[ 1548] = 0x00000008004c7518 app   CustomLoadee3 aot-linked`

-------------

Changes requested by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24223#pullrequestreview-2774638133
PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2048272791

From tpushkin at openjdk.org  Thu Apr 17 07:16:50 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 17 Apr 2025 07:16:50 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v10]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 16 Apr 2025 21:52:46 GMT, Ioi Lam  wrote:

>> Timofei Pushkin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - Empty commit to make GH update the PR
>>  - Merge remote-tracking branch 'openjdk-jdk/master' into one-loader
>>  - Implement super overshadowing warning
>>  - Omit Source classes from archive
>>  - Remove unused imports
>>  - Fix indentation
>>  - Extend ClassFromClasspath test
>>  - Remove findClass, extend explanation comments
>>  - Remove unnecessary scoping
>>  - Don't use URLClassPath
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/465c8e65...595756f3
>
> src/hotspot/share/cds/classListParser.cpp line 517:
> 
>> 515:     return;
>> 516:   }
>> 517:   assert(!supertype->is_shared_unregistered_class(), "unregistered supertype cannot be overshadowed");
> 
> Does this always prevent an unregistered class to use any other unregistered class as its super type?
> 
> I think a better check would be here:
> 
> 
>     if (!k->local_interfaces()->contains(specified_interface)) {
> +     jio_fprintf(defaultStream::error_stream(), "Specified interface %s (id %d) is not directly implemented\n",
> +           specified_interface->external_name(), _interfaces->at(i));
>       print_specified_interfaces();
>       print_actual_interfaces(k);
> +     throw exception .....      
> -     error("Specified interface %s (id %d) is not directly implemented",
> -           specified_interface->external_name(), _interfaces->at(i));
>       }

Overshadowing should be checked before attempting to load the class. Otherwise if the wrongly used super has a different classfile than the specified super we may get class loading errors (see JVMS 5.3.5.3 and 5.3.5.4), e.g. if the specified super wasn't final but we try to use a final class instead of it. I'll extend the related explanation comments in the code.

> Does this always prevent an unregistered class to use any other unregistered class as its super type?

The only way I see for another class to be used instead is for the unregistered class being loaded to reference supertypes of unexpected names in its classfile. But this is an error and it will be detected as such in the C++ code you've cited. If you have any other cases in mind please share.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2048379190

From tpushkin at openjdk.org  Thu Apr 17 07:41:36 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 17 Apr 2025 07:41:36 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v11]
In-Reply-To: 
References: 
Message-ID: 

> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app.
> 
> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible.

Timofei Pushkin has updated the pull request incrementally with two additional commits since the last revision:

 - Make RegUnregSuperTest AOTClassLinking-compatible
 - Extend overshadowing explanation comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24223/files
  - new: https://git.openjdk.org/jdk/pull/24223/files/595756f3..915987b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=09-10

  Stats: 19 lines in 3 files changed: 9 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/24223.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223

PR: https://git.openjdk.org/jdk/pull/24223

From tpushkin at openjdk.org  Thu Apr 17 07:41:41 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Thu, 17 Apr 2025 07:41:41 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v10]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 17 Apr 2025 05:45:50 GMT, Calvin Cheung  wrote:

>> Timofei Pushkin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - Empty commit to make GH update the PR
>>  - Merge remote-tracking branch 'openjdk-jdk/master' into one-loader
>>  - Implement super overshadowing warning
>>  - Omit Source classes from archive
>>  - Remove unused imports
>>  - Fix indentation
>>  - Extend ClassFromClasspath test
>>  - Remove findClass, extend explanation comments
>>  - Remove unnecessary scoping
>>  - Don't use URLClassPath
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/465c8e65...595756f3
>
> test/hotspot/jtreg/runtime/cds/appcds/customLoader/RegUnregSuperTest.java line 77:
> 
>> 75:             out.shouldContain("CustomLoadee3Child (id 3) has super-type CustomLoadee3 (id 1) overshadowed by another class with the same name");
>> 76:         } else {
>> 77:             out.shouldContain("unreg CustomLoadee3Child\n");
> 
> Could you remove the linefeed ('\n') chars?
> I'm seeing test failure when running with the `-XX:+AOTClassLinking` option.
> 
> 
> java.lang.RuntimeException: 'app   CustomLoadee3
> ' missing from stdout/stderr
> 	at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253)
> 	at RegUnregSuperTest.main(RegUnregSuperTest.java:71)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
> 	at java.base/java.lang.Thread.run(Thread.java:1447)
> 
> The expected output is there:
> `[1.686s][debug  ][cds,class] klasses[ 1548] = 0x00000008004c7518 app   CustomLoadee3 aot-linked`

Do I understand correctly that you modified the test's code to use `-XX:+AOTClassLinking` to get this error? Do you think there should be another test variant with `-XX:+AOTClassLinking` (it is easy to add)?

"\n" is used after "CustomLoadee3" because `shouldContain("unreg CustomLoadee3")` will accept either "unreg CustomLoadee3" or "unreg CustomLoadee3Child" and the second case is not what I want to detect.

Anyway, I've changed the test to pass when `-XX:+AOTClassLinking` is used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2048413693

From vklang at openjdk.org  Thu Apr 17 11:10:12 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 17 Apr 2025 11:10:12 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v56]
In-Reply-To: 
References: 
 
Message-ID: <5Fch16i4tli5STNrBlXneMqNpq5z6JhKuHNhBbf73Qg=.2c76fc01-e702-4615-b39a-64f16be89879@github.com>

On Thu, 10 Apr 2025 14:19:25 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments on original vs underlying

Last review pass? :)

src/java.base/share/classes/java/lang/StableValue.java line 204:

> 202:  *         Set.of(1, 2, 4, 8, 16, 32);
> 203:  *     private static final UnaryOperator UNDERLYING_LOG2 =
> 204:  *         i -> 31 - Integer.numberOfLeadingZeros(i);

Would boxing be necessary?i.e. what would be needed to use java.util.function.IntUnaryOperator?

src/java.base/share/classes/java/lang/StableValue.java line 318:

> 316:  * 

> 317:  * Another example, which has a more complex dependency graph, is to lazily computing the
> 318:  * Fibonacci sequence:

Suggestion:

 * Another example, which has a more complex dependency graph, is to compute the
 * Fibonacci sequence lazily:

src/java.base/share/classes/java/lang/StableValue.java line 410:

> 408:  *           parameter, and an {@linkplain #equals(Object) equals(obj)} parameter; all
> 409:  *           method parameters must be non-null or a {@link NullPointerException}
> 410:  *           will be thrown.

@minborg @mcimadamore I wonder if it makes more sense to specify that an implementation is free to synchronize on `this`, and as such, as a user, it is should be avoided to synchronize on StableValues.

This leaves the choice open to the implementations whether they want to synchonize on `this` or use some other shceme, while still discouraging users from synchronizing on StableValue instances.

src/java.base/share/classes/java/lang/StableValue.java line 415:

> 413:  *           a class and is usually neither exposed directly via accessors nor passed as
> 414:  *           a method parameter.
> 415:  *           Stable functions and collections make all reasonable efforts to provide

Suggestion:

 *           Stable functions and collections make reasonable efforts to provide

src/java.base/share/classes/java/lang/StableValue.java line 418:

> 416:  *           {@link Object#toString()} operations that do not trigger evaluation
> 417:  *           of the internal stable values when called.
> 418:  *           Stable collections have {@link Object#equals(Object)} operations that tries

Suggestion:

 *           Stable collections have {@link Object#equals(Object)} operations that try

src/java.base/share/classes/java/lang/StableValue.java line 422:

> 420:  *           As objects can be set via stable values but never removed, this can be a source
> 421:  *           of unintended memory leaks. A stable value's content is
> 422:  *           {@linkplain java.lang.ref##reachability strongly reachable}. Clients are

I wonder if "Clients" is the best word here. Perhaps "Developers"?

src/java.base/share/classes/java/lang/StableValue.java line 487:

> 485:      * 

> 486:      * If the supplier throws an (unchecked) exception, the exception is rethrown, and no
> 487:      * content is set. The most common usage is to construct a new object serving

Suggestion:

     * If the supplier throws an (unchecked) exception, the exception is rethrown and no
     * content is set. The most common usage is to construct a new object serving

src/java.base/share/classes/java/lang/StableValue.java line 571:

> 569:      * thrown by the computing thread.
> 570:      * 

> 571:      * If the provided {@code underlying} supplier throws an exception, it is relayed

Suggestion:

     * If the provided {@code underlying} supplier throws an exception, it is rethrown

src/java.base/share/classes/java/lang/StableValue.java line 670:

> 668:      * (e.g. via {@linkplain List#get(int) List::get}).
> 669:      * 

> 670:      * The provided {@code mapper} int function is guaranteed to be successfully invoked

Suggestion:

     * The provided {@code mapper} function is guaranteed to be successfully invoked

src/java.base/share/classes/java/lang/StableValue.java line 720:

> 718:      * 

> 719:      * If the provided {@code mapper} throws an exception, it is relayed to the initial
> 720:      * caller and no value associated with the provided key is recorded.

Suggestion:

     * If invoking the provided {@code mapper} function throws an exception, it is rethrown to the initial
     * caller and no value associated with the provided key is recorded.

src/java.base/share/classes/java/util/ImmutableCollections.java line 36:

> 34: import java.lang.reflect.Array;
> 35: import java.util.function.BiConsumer;
> 36: import java.util.function.BiFunction;

Make sure to update the copyright years of all the files modified in this PR.

test/jdk/java/lang/StableValue/StableMapTest.java line 140:

> 138:         String actual = newMap().toString();
> 139:         assertTrue(actual.startsWith("{"));
> 140:         for (int key:KEYS) {

Suggestion:

        for (int key : KEYS) {

test/jdk/java/lang/StableValue/StableMapTest.java line 317:

> 315:                      Consumer> consumer) implements Consumer> {
> 316:         @java.lang.Override
> 317:         public void   accept(Map map) { consumer.accept(map); }

Suggestion:

        public void accept(Map map) { consumer.accept(map); }

test/jdk/java/lang/StableValue/StableMapTest.java line 324:

> 322:     static Stream nullAverseOperations() {
> 323:         return Stream.of(
> 324:                 new Operation("forEach",     m -> m.forEach(null))

Suggestion:

            new Operation("forEach",     m -> m.forEach(null))

test/jdk/java/lang/StableValue/StableMapTest.java line 341:

> 339:                 new Operation("replace2",          m -> m.replace(KEY, 1)),
> 340:                 new Operation("replace3",          m -> m.replace(KEY, KEY, 1)),
> 341:                 new Operation("replaceAll",        m -> m.replaceAll((a, _) -> a))

Suggestion:

            new Operation("clear",             Map::clear),
            new Operation("compute",           m -> m.compute(KEY, (_, _) -> 1)),
            new Operation("computeIfAbsent",   m -> m.computeIfAbsent(KEY, _ -> 1)),
            new Operation("computeIfPresent",  m -> m.computeIfPresent(KEY, (_, _) -> 1)),
            new Operation("merge",             m -> m.merge(KEY, KEY, (a, _) -> a)),
            new Operation("put",               m -> m.put(0, 0)),
            new Operation("putAll",            m -> m.putAll(Map.of())),
            new Operation("remove1",           m -> m.remove(KEY)),
            new Operation("remove2",           m -> m.remove(KEY, KEY)),
            new Operation("replace2",          m -> m.replace(KEY, 1)),
            new Operation("replace3",          m -> m.replace(KEY, KEY, 1)),
            new Operation("replaceAll",        m -> m.replaceAll((a, _) -> a))

-------------

PR Review: https://git.openjdk.org/jdk/pull/23972#pullrequestreview-2775117821
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2048580493
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2048568958
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2048697517
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2048698149
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2048698693
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2048700350
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2048703097
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2048705582
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2048707720
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2048709836
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2048720211
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2048722073
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2048723018
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2048723430
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2048724778

From duke at openjdk.org  Thu Apr 17 11:26:10 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 17 Apr 2025 11:26:10 GMT
Subject: RFR: 8077587: BigInteger Roots [v6]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  optimize division in loop iteration of nth root

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/9c32ce47..7ff919b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=04-05

  Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From duke at openjdk.org  Thu Apr 17 12:19:37 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 17 Apr 2025 12:19:37 GMT
Subject: RFR: 8077587: BigInteger Roots [v7]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  An optimization

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/7ff919b3..1f5a9b48

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From erikj at openjdk.org  Thu Apr 17 12:50:48 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 17 Apr 2025 12:50:48 GMT
Subject: RFR: 8353214: Add testing with --enable-preview
In-Reply-To: <-PL85c8ObM1KN0uVIMTglhh6apK6fWXHFO_XdbE0UWI=.589ff6c6-b65a-48c8-807a-1960d72cac09@github.com>
References: <-PL85c8ObM1KN0uVIMTglhh6apK6fWXHFO_XdbE0UWI=.589ff6c6-b65a-48c8-807a-1960d72cac09@github.com>
Message-ID: 

On Thu, 17 Apr 2025 00:24:50 GMT, Leonid Mesnik  wrote:

> Added problemlists and and requires for execution tests with --enable-preview.
> 
> The --enable-preview features might significantly change VM/JDK behavior and sometimes it is useful to run tests with preview features enabled. Eventually preview features should be made default and it is expected that all tests should still work. 
> 
> The tests that are not compatible with --enable-preview, usually because of compilation mode are marked with corresponding requires tag.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24706#pullrequestreview-2775610558

From duke at openjdk.org  Thu Apr 17 13:18:42 2025
From: duke at openjdk.org (Johannes Graham)
Date: Thu, 17 Apr 2025 13:18:42 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 16 Apr 2025 17:40:39 GMT, Johannes Graham  wrote:

>> The `DigitList` class used in `DecimalFormat` does not reset the `data` array in its clone method. This can cause interference when clones are used concurrently.
>
> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix catch block

Thank you all for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24598#issuecomment-2812861383

From duke at openjdk.org  Thu Apr 17 13:18:42 2025
From: duke at openjdk.org (duke)
Date: Thu, 17 Apr 2025 13:18:42 GMT
Subject: RFR: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently [v9]
In-Reply-To: 
References: 
 
Message-ID: <0Unk8TQnamXhqho-gr-7EntHqPtYtNKzZQwcd8HeKB8=.7003858a-ee04-41d8-9686-8d973e154058@github.com>

On Wed, 16 Apr 2025 17:40:39 GMT, Johannes Graham  wrote:

>> The `DigitList` class used in `DecimalFormat` does not reset the `data` array in its clone method. This can cause interference when clones are used concurrently.
>
> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix catch block

@j3graham 
Your change (at version 6c23e27eaabd878808f8524cfdc3dc8255e397b5) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24598#issuecomment-2812866429

From ihse at openjdk.org  Thu Apr 17 13:59:43 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 17 Apr 2025 13:59:43 GMT
Subject: RFR: 8352044: Add --with-import-jvms to configure
In-Reply-To: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
Message-ID: 

On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie  wrote:

> We should allow pre-built JVMs to be included in a build, so they are just copied into place, and the jvm.cfg file properly updated.

`KEEPALIVE`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2813019172

From ihse at openjdk.org  Thu Apr 17 14:04:59 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 17 Apr 2025 14:04:59 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 16 Apr 2025 16:14:39 GMT, Naoto Sato  wrote:

> We will probably need to make sure things are ok on Windows as well (they are the other confusing environment)

Windows is much more painful to work with, since there is no correspondence of `LC_ALL`; you must set the user's locale. There is a rather long paragraph detailing the requirements for building without problems in the build README.

Is there some specific problem you are worried about on Windows that you were thinking about?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2813033188

From mbaesken at openjdk.org  Thu Apr 17 14:05:01 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 17 Apr 2025 14:05:01 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 14 Apr 2025 12:53:35 GMT, Magnus Ihse Bursie  wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim

Little additional info regarding AIX, when allowing  locale C in the basic.m4 too by patching your change , the build works nicely for me,  even on a AIX machine without  the C.UTF-8 or en_US.UTF-8 locales.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2813037836

From dfuchs at openjdk.org  Thu Apr 17 14:43:43 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 17 Apr 2025 14:43:43 GMT
Subject: RFR: 8354424: java/util/logging/LoggingDeadlock5.java fails
 intermittently in tier6 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 16 Apr 2025 17:37:07 GMT, David Beaumont  wrote:

>> Increasing timeout for deadlock detection and adjusting for the timeout factor in higher tiers.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing test from the problem list.

The proposed changes look good to me.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24687#pullrequestreview-2776022724

From ihse at openjdk.org  Thu Apr 17 14:48:23 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 17 Apr 2025 14:48:23 GMT
Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8
 characters
Message-ID: 

As part of the UTF-8 cleaning up done in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where and how we are using unicode sequences (`\uXXXX`). In several string literals, I think the unicode sequences still has merit, if they improve clarity or readability of the code. Some instances are more gray zone. But the places where it does not make sense at all are in comments, as part of fluid text comments. There they are just disruptive and not helpful at all. I tried to locate all such places (but I might have missed places, I did not do a proper lexical analysis to find comments) and fix them.

99% of this fix is to turn poor `Peter von der Ah\u00e9` into `Peter von der Ah?`. ? 

I checked some random samples on when this was introduced to see if there were some particular commit that mistreated the encoding, but they have been there since the original release of the open JDK source code.

There are likely many more places where direct UTF-8 encoded characters is preferable to unicode sequences, but this seemed like a safe and trivial first start.

-------------

Commit messages:
 - 8354968: Replace unicode sequences in comment text with UTF-8 characters

Changes: https://git.openjdk.org/jdk/pull/24727/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24727&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354968
  Stats: 158 lines in 153 files changed: 0 ins; 2 del; 156 mod
  Patch: https://git.openjdk.org/jdk/pull/24727.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24727/head:pull/24727

PR: https://git.openjdk.org/jdk/pull/24727

From ccheung at openjdk.org  Thu Apr 17 15:39:47 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 17 Apr 2025 15:39:47 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v10]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 17 Apr 2025 07:38:27 GMT, Timofei Pushkin  wrote:

>> test/hotspot/jtreg/runtime/cds/appcds/customLoader/RegUnregSuperTest.java line 77:
>> 
>>> 75:             out.shouldContain("CustomLoadee3Child (id 3) has super-type CustomLoadee3 (id 1) overshadowed by another class with the same name");
>>> 76:         } else {
>>> 77:             out.shouldContain("unreg CustomLoadee3Child\n");
>> 
>> Could you remove the linefeed ('\n') chars?
>> I'm seeing test failure when running with the `-XX:+AOTClassLinking` option.
>> 
>> 
>> java.lang.RuntimeException: 'app   CustomLoadee3
>> ' missing from stdout/stderr
>> 	at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253)
>> 	at RegUnregSuperTest.main(RegUnregSuperTest.java:71)
>> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
>> 	at java.base/java.lang.Thread.run(Thread.java:1447)
>> 
>> The expected output is there:
>> `[1.686s][debug  ][cds,class] klasses[ 1548] = 0x00000008004c7518 app   CustomLoadee3 aot-linked`
>
> Do I understand correctly that you modified the test's code to use `-XX:+AOTClassLinking` to get this error? Do you think there should be another test variant with `-XX:+AOTClassLinking` (it is easy to add)?
> 
> "\n" is used after "CustomLoadee3" because `shouldContain("unreg CustomLoadee3")` will accept either "unreg CustomLoadee3" or "unreg CustomLoadee3Child" and the second case is not what I want to detect.
> 
> Anyway, I've changed the test to pass when `-XX:+AOTClassLinking` is used.

No, I didn't modify the test code but ran your patch through our internal testing tiers. One of the tier specifies the `-XX:+AOTClassLinking` option. You can also run it via jtreg command line using the `-javaoptions`, e.g. `-javaoptions:"-XX:+AOTClassLinking"`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2049215878

From bpb at openjdk.org  Thu Apr 17 16:24:17 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Apr 2025 16:24:17 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
Message-ID: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>

Implement the requested methods and add a test thereof.

-------------

Commit messages:
 - 8354724: BufferedReader readAllLines and readString methods

Changes: https://git.openjdk.org/jdk/pull/24728/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354724
  Stats: 176 lines in 2 files changed: 175 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728

PR: https://git.openjdk.org/jdk/pull/24728

From duke at openjdk.org  Thu Apr 17 16:24:53 2025
From: duke at openjdk.org (Johannes Graham)
Date: Thu, 17 Apr 2025 16:24:53 GMT
Subject: Integrated: 8354522: Clones of DecimalFormat cause interferences when
 used concurrently
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Apr 2025 17:31:08 GMT, Johannes Graham  wrote:

> The `DigitList` class used in `DecimalFormat` does not reset the `data` array in its clone method. This can cause interference when clones are used concurrently.

This pull request has now been integrated.

Changeset: 04c32fc0
Author:    Johannes Graham 
Committer: Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/04c32fc08a67eaf6d3f47a0f9ea3d620b7ec6a07
Stats:     174 lines in 2 files changed: 173 ins; 0 del; 1 mod

8354522: Clones of DecimalFormat cause interferences when used concurrently

Reviewed-by: jlu, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/24598

From bpb at openjdk.org  Thu Apr 17 16:29:55 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Apr 2025 16:29:55 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: <3LnpcYz8g2YL1ohp4jD8qt4wBgpL-K4zUgFkh1YnSbM=.608a0da1-ec14-4319-a845-27a4af7a97d2@github.com>

On Thu, 17 Apr 2025 16:18:55 GMT, Brian Burkhalter  wrote:

> Implement the requested methods and add a test thereof.

A CSR will be filed if the discussion in this request converges to consensus.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2813488383

From naoto at openjdk.org  Thu Apr 17 16:29:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 17 Apr 2025 16:29:56 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 17 Apr 2025 14:01:07 GMT, Magnus Ihse Bursie  wrote:

> Is there some specific problem you are worried about on Windows that you were thinking about?

I would have tested on non-English (preferrably Chinese/Japanese) Windows where users set it to English. I believe we had issues from contributors in those areas.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2813487827

From duke at openjdk.org  Thu Apr 17 16:39:52 2025
From: duke at openjdk.org (Hendrik Schick)
Date: Thu, 17 Apr 2025 16:39:52 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: <3VdFkk6LpCxsnHMHLfiCAp7HQL-gCYyBgeWqWPmfhzw=.e7a2c3d0-7493-43b8-bde3-d109e5ef00ff@github.com>

On Thu, 17 Apr 2025 16:18:55 GMT, Brian Burkhalter  wrote:

> Implement the requested methods and add a test thereof.

src/java.base/share/classes/java/io/BufferedReader.java line 459:

> 457:      * @since 25
> 458:      */
> 459:     public  String readString() throws IOException {

Suggestion:

    public String readString() throws IOException {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2049309525

From naoto at openjdk.org  Thu Apr 17 16:39:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 17 Apr 2025 16:39:51 GMT
Subject: RFR: 8354464: Additional cleanup setting up native.encoding [v3]
In-Reply-To: 
References: 
 
Message-ID: <1wnmYTOcJn8SpjwCGQLVDP0AhRrNjmffkddQlOy8IyQ=.6c639fa7-a856-49dc-98c2-07181f091dee@github.com>

On Thu, 17 Apr 2025 00:30:00 GMT, Stuart Marks  wrote:

>> Remove the #ifdef MACOSX from platform-independent System.c, which (on Mac) sets native.encoding from sprops.encoding or (on non-Mac Unix and Windows) sets native.encoding from sprops.sun_jnu_encoding. After this removal, the native.encoding property will be set from sprops.encoding and the sun.jnu.encoding property will be set from sprops.sun_jnu_encoding.
>> 
>> Change the windows java_props_md.c so that it initializes sprops.sun_jnu_encoding and then copies that value to sprops.encoding. Previously, sprops.encoding was initialized with data from other Windows APIs, but this value was ignored by platform-independent code, which was kind of confusing.
>> 
>> There are no changes to the Unix (Mac & non-Mac) platform-specific code. It already has code to set sprops.encoding and sprops.sun_jnu_encoding properly, including macOS-specific code to set the latter to UTF-8 unconditionally.
>> 
>> There should be no behavior changes on any platform.
>> 
>> I changed variable names in windows/java_props_md.c to make it clear that the values stored into them are unused. Of course there are other possibilities here, such as changing the interface to SetupI18nProps(). I'm open to suggestions.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove encoding parameter from SetupI18nProps.

LGTM!

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24607#pullrequestreview-2776354522

From bpb at openjdk.org  Thu Apr 17 16:45:54 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Apr 2025 16:45:54 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
In-Reply-To: <3VdFkk6LpCxsnHMHLfiCAp7HQL-gCYyBgeWqWPmfhzw=.e7a2c3d0-7493-43b8-bde3-d109e5ef00ff@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <3VdFkk6LpCxsnHMHLfiCAp7HQL-gCYyBgeWqWPmfhzw=.e7a2c3d0-7493-43b8-bde3-d109e5ef00ff@github.com>
Message-ID: 

On Thu, 17 Apr 2025 16:36:53 GMT, Hendrik Schick  wrote:

>> Implement the requested methods and add a test thereof.
>
> src/java.base/share/classes/java/io/BufferedReader.java line 459:
> 
>> 457:      * @since 25
>> 458:      */
>> 459:     public  String readString() throws IOException {
> 
> Suggestion:
> 
>     public String readString() throws IOException {

Thanks. Will be fixed in next commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2049318049

From jlu at openjdk.org  Thu Apr 17 17:05:59 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 17 Apr 2025 17:05:59 GMT
Subject: RFR: 8354344: Test behavior after cut-over for future ISO 4217
 currency
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Apr 2025 00:15:47 GMT, Naoto Sato  wrote:

> > As the test tracks the ISO 4217 data, manual testing of this change can be done by modifying the cut-over year from 2025 to 2026 for the `CW=ANG;2025-04-01-04-00-00;XCG` entry for both the JDK and test data.
> 
> Would it be possible to use `currency.properties` file to provide a test transition, and use this logic test the validity, so that it is not a manual testing? Still it is not 100% same with the data from `currency.data`, but at least provides the transition logic validity, possibly for both simple and special currencies.

That's an interesting idea, I think it is possible. As you stated, the logic is different, but it would guarantee that the second run is indeed testing in the future. I'm not sure how combining a currency.properties override with the main ValidateISO4217 test will turn out though since the test should track 1 to 1 with the ISO data. Will look into it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24701#issuecomment-2813567220

From alanb at openjdk.org  Thu Apr 17 17:08:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Apr 2025 17:08:40 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: 

On Thu, 17 Apr 2025 16:18:55 GMT, Brian Burkhalter  wrote:

> Implement the requested methods and add a test thereof.

src/java.base/share/classes/java/io/BufferedReader.java line 440:

> 438:      * Reads all characters into a string.
> 439:      *
> 440:      * 
 This method reads all content including the line separators in

It would be more accurate to say that it reads the remaining content as there is may some reading done before this method is called (I realize this isn't the expected usage of this method but it has to allow for it).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2049352391

From matsaave at openjdk.org  Thu Apr 17 17:14:59 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 17 Apr 2025 17:14:59 GMT
Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking
In-Reply-To: 
References: 
Message-ID: 

On Wed, 16 Apr 2025 18:21:41 GMT, Calvin Cheung  wrote:

> This RFE allows --add-opens to be specified for AOT cache creation. AOT cache can be used during production run with --add-opens option as long as the same set of options is used during assembly phase.
> 
> Passed tiers 1 - 4 testing.

LGTM!

-------------

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24695#pullrequestreview-2776439517

From liach at openjdk.org  Thu Apr 17 17:25:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Apr 2025 17:25:40 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: 

On Thu, 17 Apr 2025 16:18:55 GMT, Brian Burkhalter  wrote:

> Implement the requested methods and add a test thereof.

Is there a particular reason that these methods should exist only on `BufferedReader` but not the base `Reader`? Similar read-all operation `InputStream::readAllBytes` exists on the base `InputStream` class.

src/java.base/share/classes/java/io/BufferedReader.java line 419:

> 417:      *
> 418:      * @apiNote
> 419:      * 
 This method is intended for simple cases where it is convenient

Suggestion:

     * This method is intended for simple cases where it is convenient

API notes already have a dd/dt block, no need for extra paragraphs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2813602189
PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2049374273

From duke at openjdk.org  Thu Apr 17 17:32:57 2025
From: duke at openjdk.org (Johannes Graham)
Date: Thu, 17 Apr 2025 17:32:57 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: 

On Thu, 17 Apr 2025 16:18:55 GMT, Brian Burkhalter  wrote:

> Implement the requested methods and add a test thereof.

test/jdk/java/io/BufferedReader/ReadAll.java line 34:

> 32: 
> 33: import java.io.BufferedReader;
> 34: import java.io.File;

Cosmetic thought - I think this could all be done with Path, avoiding File and friends.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2049387753

From duke at openjdk.org  Thu Apr 17 17:32:57 2025
From: duke at openjdk.org (Johannes Graham)
Date: Thu, 17 Apr 2025 17:32:57 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
Message-ID: <6-naTBaPcKARea9h216XECYUwHtihmCh2Irv8MBV55w=.ec297e74-287a-403e-bc06-0b4d3b6b449d@github.com>

On Thu, 17 Apr 2025 17:28:12 GMT, Johannes Graham  wrote:

>> Implement the requested methods and add a test thereof.
>
> test/jdk/java/io/BufferedReader/ReadAll.java line 34:
> 
>> 32: 
>> 33: import java.io.BufferedReader;
>> 34: import java.io.File;
> 
> Cosmetic thought - I think this could all be done with Path, avoiding File and friends.

possibly even using Reader.of(CharSequence)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2049389973

From joehw at openjdk.org  Thu Apr 17 17:47:22 2025
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 17 Apr 2025 17:47:22 GMT
Subject: RFR: 8354774: DocumentBuilderFactory getAttribute throws NPE
Message-ID: 

Fix a NPE on calling DocumentBuilderFactory::getAttribute. This issue was found during the previous JCK test (JCK-7322355). The JCK failure was from a different method call, but it appears this is the root cause.

Also in this patch: consolidates get and set properties to use the same Util methods to reduce potential errors when code changes.

Test:
    Tier1 - 3 passed
    JCK test passed (will update JCK-7322355 once this patch is integrated)

-------------

Commit messages:
 - 8354774: DocumentBuilderFactory getAttribute throws NPE

Changes: https://git.openjdk.org/jdk/pull/24732/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24732&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354774
  Stats: 336 lines in 11 files changed: 220 ins; 67 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/24732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24732/head:pull/24732

PR: https://git.openjdk.org/jdk/pull/24732

From vlivanov at openjdk.org  Thu Apr 17 17:54:33 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 17 Apr 2025 17:54:33 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v9]
In-Reply-To: 
References: 
Message-ID: <9P_rdGJAfXNZMa82oVtdWXdPO0krCVCRRUkve_Z-ZpU=.9f38ab8c-ce13-47c0-b8b3-a8fa0f9048c1@github.com>

> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
> 
> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
> 
> The patch consists of the following parts:
>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
> 
> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
> 
> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
> 
> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
> 
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
> 
> Thanks!

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  RVV and SVE adjustments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24462/files
  - new: https://git.openjdk.org/jdk/pull/24462/files/1ade1ffd..e2b762ec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=07-08

  Stats: 19 lines in 1 file changed: 2 ins; 11 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24462/head:pull/24462

PR: https://git.openjdk.org/jdk/pull/24462

From henryjen at openjdk.org  Thu Apr 17 18:02:55 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 17 Apr 2025 18:02:55 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine
In-Reply-To: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
Message-ID: 

On Fri, 11 Apr 2025 22:45:55 GMT, Chen Liang  wrote:

> When jdeps was migrated from old classfile to ClassFile API, the parsing semantic changed - error checks are now made lazily, and nested crashes from malformed signature or other problems is now latent, after a `ClassModel` instance is available. (The old error check existed only for constructing a `ClassModel`)
> 
> To address this issue, I have updated the way of iterating class files to be handler/consumer based like in the ClassFile API. This has the advantage that when one invocation of the handler fails of a `ClassFileError`, other invocations for other class files can proceed, and the exception handler has sufficient information to report a useful message indicating the source of error.
> 
> For the particular example of examining a proguard processed `dummy-scala.jar`, here is the new output of `jdeps dummy-scala.jar`:
> 
> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 59, expected an identifier: Lscala/collection/immutable/TreeMap$TreeMapBuilder.;: scala/collection/immutable/TreeMap$TreeMapBuilder.class (dummy-scala.jar)
> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 49, expected an identifier: Lscala/collection/parallel/mutable/ParArray.;: scala/collection/parallel/mutable/ParArray.class (dummy-scala.jar)
> 
> 
> Now, jdeps shows the bad class files. Inspection into the files reveal that proguard incorrectly deleted the simple class names with trailing `$`, for example, the original signature of the broken ParArray was `Lscala/collection/parallel/mutable/ParArray.ParArrayIterator$;`, so the `ParArrayIterator$` part was incorrectly dropped by proguard.
> 
> Testing: langtools/tools/jdeps.

src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java line 105:

> 103: 
> 104:     protected void skipEntry(ClassFileError ex, String fileName) {
> 105:         skippedEntries.add(String.format("%s: %s", ex.toString(), fileName));

The second parameter is not always a straightforward filename, consider to rename it, perhaps `entryPath`?

src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java line 237:

> 235:                               skipEntry(ex, e.toString());
> 236:                           } catch (IOException ex) {
> 237:                               throw new UncheckedIOException(ex);

Just to point out this was leading to ClassFileError in the old implementation, new implementation will relay the IOException, which I think is proper.

src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java line 339:

> 337:                         });
> 338:             } catch (UncheckedIOException ex) {
> 339:                 throw ex.getCause();

IOException used to skip entry with message and continue, the new behavior would change. I am not certain this is behavior compatible.
I doubt IOException would be recoverable on different entry, but it might in rare cases?

src/jdk.jdeps/share/classes/com/sun/tools/jdeps/DependencyFinder.java line 176:

> 174:         FutureTask> task = new FutureTask<>(() -> {
> 175:             Set targets = new HashSet<>();
> 176:             archive.reader().processClassFiles(cf -> {

I prefer the naming convention with forEach for operation to iterate through rather than have a `process` on a reader. Perhaps named like `forEachClassFile`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24604#discussion_r2049319406
PR Review Comment: https://git.openjdk.org/jdk/pull/24604#discussion_r2049411874
PR Review Comment: https://git.openjdk.org/jdk/pull/24604#discussion_r2049425413
PR Review Comment: https://git.openjdk.org/jdk/pull/24604#discussion_r2049378312

From vlivanov at openjdk.org  Thu Apr 17 18:03:47 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 17 Apr 2025 18:03:47 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v10]
In-Reply-To: 
References: 
Message-ID: 

> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
> 
> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
> 
> The patch consists of the following parts:
>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
> 
> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
> 
> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
> 
> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
> 
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
> 
> Thanks!

Vladimir Ivanov 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 24 additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into vector.math.01.java
 - RVV and SVE adjustments
 - fix broken merge
 - Merge branch 'master' into vector.math.01.java
 - Fix debugName handling
 - Merge branch 'master' into vector.math.01.java
 - RVV and SVE adjustments
 - Merge branch 'master' into vector.math.01.java
 - Fix windows-aarch64 build failure
 - features_string -> cpu_info_string
 - ... and 14 more: https://git.openjdk.org/jdk/compare/bba47808...88eacc48

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24462/files
  - new: https://git.openjdk.org/jdk/pull/24462/files/e2b762ec..88eacc48

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=08-09

  Stats: 5947 lines in 148 files changed: 5156 ins; 446 del; 345 mod
  Patch: https://git.openjdk.org/jdk/pull/24462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24462/head:pull/24462

PR: https://git.openjdk.org/jdk/pull/24462

From bpb at openjdk.org  Thu Apr 17 18:04:51 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Apr 2025 18:04:51 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: 

On Thu, 17 Apr 2025 16:18:55 GMT, Brian Burkhalter  wrote:

> Implement the requested methods and add a test thereof.

> /csr needed

I was going to do that _after_ consensus had been achieved here. It's extra work to create a CSR before that point, especially as that point might not be reached.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2813683716

From vlivanov at openjdk.org  Thu Apr 17 18:10:46 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 17 Apr 2025 18:10:46 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v5]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Thu, 17 Apr 2025 01:36:39 GMT, Xiaohong Gong  wrote:

>> How does it work now? The code in `generate_vector_math_stubs()` in `stubGenerator_aarch64.cpp` only populates `VEC_SIZE_SCALABLE` shapes with SVE versions.
>
> Please see the `addr` definition code in https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/vectorIntrinsics.cpp#L1877 . If queried `addr` returns `nullptr` for 256-bit vectors, and the arch supports scalable vector, then the `addr` will be assigned to the scalable ones.

Ah, ok. Thanks for the pointer. I aligned lookup logic with existing behavior. 

I'd like to double-check one things: is it fine to use scalable vector variants for fixed-sized vector shapes of smaller size without any explicit masking/stripping of upper vector part?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2049436133

From bpb at openjdk.org  Thu Apr 17 18:12:55 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Apr 2025 18:12:55 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
Message-ID: 

On Thu, 17 Apr 2025 17:20:57 GMT, Chen Liang  wrote:

> Is there a particular reason that these methods should exist only on `BufferedReader` but not the base `Reader`?

Good question. Perhaps @RogerRiggs could comment on that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2813698152

From smarks at openjdk.org  Thu Apr 17 18:33:55 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 17 Apr 2025 18:33:55 GMT
Subject: Integrated: 8354464: Additional cleanup setting up native.encoding
In-Reply-To: 
References: 
Message-ID: 

On Sat, 12 Apr 2025 02:19:35 GMT, Stuart Marks  wrote:

> Remove the #ifdef MACOSX from platform-independent System.c, which (on Mac) sets native.encoding from sprops.encoding or (on non-Mac Unix and Windows) sets native.encoding from sprops.sun_jnu_encoding. After this removal, the native.encoding property will be set from sprops.encoding and the sun.jnu.encoding property will be set from sprops.sun_jnu_encoding.
> 
> Change the windows java_props_md.c so that it initializes sprops.sun_jnu_encoding and then copies that value to sprops.encoding. Previously, sprops.encoding was initialized with data from other Windows APIs, but this value was ignored by platform-independent code, which was kind of confusing.
> 
> There are no changes to the Unix (Mac & non-Mac) platform-specific code. It already has code to set sprops.encoding and sprops.sun_jnu_encoding properly, including macOS-specific code to set the latter to UTF-8 unconditionally.
> 
> There should be no behavior changes on any platform.
> 
> I changed variable names in windows/java_props_md.c to make it clear that the values stored into them are unused. Of course there are other possibilities here, such as changing the interface to SetupI18nProps(). I'm open to suggestions.

This pull request has now been integrated.

Changeset: 7b061885
Author:    Stuart Marks 
URL:       https://git.openjdk.org/jdk/commit/7b0618859a7764b0d4c8b893a19dfb64f4351c07
Stats:     38 lines in 3 files changed: 2 ins; 26 del; 10 mod

8354464: Additional cleanup setting up native.encoding

Reviewed-by: naoto, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/24607

From smarks at openjdk.org  Thu Apr 17 18:33:54 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 17 Apr 2025 18:33:54 GMT
Subject: RFR: 8354464: Additional cleanup setting up native.encoding [v2]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: <2MhmY_gCKb_hB_PfWD6YXZPpy_IxqJRX57hJYlzqRpo=.846b1b71-33c1-4506-8076-ec76e9dfe846@github.com>

On Thu, 17 Apr 2025 00:26:49 GMT, Stuart Marks  wrote:

>> I belive they can be removed as they are no where used (and I don't think it will be used for `stdin.encoding` either) So I prefer removing those unused code now.
>
> OK, I've done so. Now testing on Windows....

(CI run built and passed all tests, including on Windows.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24607#discussion_r2049461886

From bpb at openjdk.org  Thu Apr 17 18:45:13 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Apr 2025 18:45:13 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v2]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: 

> Implement the requested methods and add a test thereof.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8354724: Address all PR comments to now

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/9fd92356..b5d82665

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=00-01

  Stats: 40 lines in 2 files changed: 10 ins; 2 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/24728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728

PR: https://git.openjdk.org/jdk/pull/24728

From bpb at openjdk.org  Thu Apr 17 18:45:14 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Apr 2025 18:45:14 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v2]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
Message-ID: 

On Thu, 17 Apr 2025 17:05:54 GMT, Alan Bateman  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8354724: Address all PR comments to now
>
> src/java.base/share/classes/java/io/BufferedReader.java line 440:
> 
>> 438:      * Reads all characters into a string.
>> 439:      *
>> 440:      * 
 This method reads all content including the line separators in
> 
> It would be more accurate to say that it reads the remaining content as there is may some reading done before this method is called (I realize this isn't the expected usage of this method but it has to allow for it).

Updated in b5d8266.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2049474932

From bpb at openjdk.org  Thu Apr 17 18:45:13 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Apr 2025 18:45:13 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v2]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
Message-ID: 

On Thu, 17 Apr 2025 17:19:03 GMT, Chen Liang  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8354724: Address all PR comments to now
>
> src/java.base/share/classes/java/io/BufferedReader.java line 419:
> 
>> 417:      *
>> 418:      * @apiNote
>> 419:      * 
 This method is intended for simple cases where it is convenient
> 
> Suggestion:
> 
>      * This method is intended for simple cases where it is convenient
> 
> API notes already have a dd/dt block, no need for extra paragraphs.

Thanks. Fixed in b5d8266.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2049475296

From bpb at openjdk.org  Thu Apr 17 18:45:14 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Apr 2025 18:45:14 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v2]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <3VdFkk6LpCxsnHMHLfiCAp7HQL-gCYyBgeWqWPmfhzw=.e7a2c3d0-7493-43b8-bde3-d109e5ef00ff@github.com>
 
Message-ID: 

On Thu, 17 Apr 2025 16:42:54 GMT, Brian Burkhalter  wrote:

>> src/java.base/share/classes/java/io/BufferedReader.java line 459:
>> 
>>> 457:      * @since 25
>>> 458:      */
>>> 459:     public  String readString() throws IOException {
>> 
>> Suggestion:
>> 
>>     public String readString() throws IOException {
>
> Thanks. Will be fixed in next commit.

Fixed in b5d8266.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2049474699

From bpb at openjdk.org  Thu Apr 17 18:45:14 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Apr 2025 18:45:14 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v2]
In-Reply-To: <6-naTBaPcKARea9h216XECYUwHtihmCh2Irv8MBV55w=.ec297e74-287a-403e-bc06-0b4d3b6b449d@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 <6-naTBaPcKARea9h216XECYUwHtihmCh2Irv8MBV55w=.ec297e74-287a-403e-bc06-0b4d3b6b449d@github.com>
Message-ID: 

On Thu, 17 Apr 2025 17:30:06 GMT, Johannes Graham  wrote:

>> test/jdk/java/io/BufferedReader/ReadAll.java line 34:
>> 
>>> 32: 
>>> 33: import java.io.BufferedReader;
>>> 34: import java.io.File;
>> 
>> Cosmetic thought - I think this could all be done with Path, avoiding File and friends.
>
> possibly even using Reader.of(CharSequence)

Test modified in b5d8266.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2049475648

From rriggs at openjdk.org  Thu Apr 17 19:06:01 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 17 Apr 2025 19:06:01 GMT
Subject: RFR: 8354464: Additional cleanup setting up native.encoding [v3]
In-Reply-To: 
References: 
 
Message-ID: <3_UAu4Lp5SJ-b3NAszLshWQ1BMX02c-eQPeYOdcNdE0=.31cb9b8d-751e-4e87-aeb7-8470071faf25@github.com>

On Thu, 17 Apr 2025 00:30:00 GMT, Stuart Marks  wrote:

>> Remove the #ifdef MACOSX from platform-independent System.c, which (on Mac) sets native.encoding from sprops.encoding or (on non-Mac Unix and Windows) sets native.encoding from sprops.sun_jnu_encoding. After this removal, the native.encoding property will be set from sprops.encoding and the sun.jnu.encoding property will be set from sprops.sun_jnu_encoding.
>> 
>> Change the windows java_props_md.c so that it initializes sprops.sun_jnu_encoding and then copies that value to sprops.encoding. Previously, sprops.encoding was initialized with data from other Windows APIs, but this value was ignored by platform-independent code, which was kind of confusing.
>> 
>> There are no changes to the Unix (Mac & non-Mac) platform-specific code. It already has code to set sprops.encoding and sprops.sun_jnu_encoding properly, including macOS-specific code to set the latter to UTF-8 unconditionally.
>> 
>> There should be no behavior changes on any platform.
>> 
>> I changed variable names in windows/java_props_md.c to make it clear that the values stored into them are unused. Of course there are other possibilities here, such as changing the interface to SetupI18nProps(). I'm open to suggestions.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove encoding parameter from SetupI18nProps.

I probably would have waited to integrate until the person who requested changes had a chance to re-approve.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24607#issuecomment-2813794530

From asemenyuk at openjdk.org  Thu Apr 17 19:06:25 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 17 Apr 2025 19:06:25 GMT
Subject: RFR: 8354985: Add unit tests for Executor class from jpackage test lib
Message-ID: 

- Add tests covering command output handling in the Executor class
 - Fix revealed bugs
 - Add a couple of `Executor.of()` convenience methods

The test is implemented in a way that it will remain mostly unchanged when Executor supports disabling of stderr and stdout streams.

-------------

Commit messages:
 - Add tests for Executor and fix revealed bugs.

Changes: https://git.openjdk.org/jdk/pull/24737/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24737&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354985
  Stats: 393 lines in 2 files changed: 380 ins; 6 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24737.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24737/head:pull/24737

PR: https://git.openjdk.org/jdk/pull/24737

From asemenyuk at openjdk.org  Thu Apr 17 19:25:00 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 17 Apr 2025 19:25:00 GMT
Subject: RFR: 8354985: Add unit tests for Executor class from jpackage test
 lib
In-Reply-To: 
References: 
Message-ID: 

On Thu, 17 Apr 2025 18:53:16 GMT, Alexey Semenyuk  wrote:

> - Add tests covering command output handling in the Executor class
>  - Fix revealed bugs
>  - Add a couple of `Executor.of()` convenience methods
> 
> The test is implemented in a way that it will remain mostly unchanged when Executor supports disabling of stderr and stdout streams.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24737#issuecomment-2813829620

From rriggs at openjdk.org  Thu Apr 17 19:30:48 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 17 Apr 2025 19:30:48 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v2]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
Message-ID: 

On Thu, 17 Apr 2025 18:45:13 GMT, Brian Burkhalter  wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8354724: Address all PR comments to now

The base `Reader` class has no concept of lines, only a stream of `char`.
The BufferedReader methods for `readline()`, `Stream`, and these new line oriented methods are complementary.

src/java.base/share/classes/java/io/BufferedReader.java line 417:

> 415:      * the expression:
> 416:      * 
{@link #lines()}.toList()

> 417:      *

It is worth noting that if an IOException occurs, the reader and underlying stream are left in an unpredictable state?

With a normal or exceptional return should anything be said about the state of the underlying stream?
The corresponding method on Files ensures the reader is closed (and propagates to the underlying stream).

src/java.base/share/classes/java/io/BufferedReader.java line 426:

> 424:      *             {@code List} is modifiable is implementation dependent,
> 425:      *             hence not specified
> 426:      *

Does the rationale used in Files to leaving this indeterminate apply here?
I'd think it would be better to say its not-modifyable.
Here its free/cheap, the Stream.toList() method creates an un-modifiableList.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24728#pullrequestreview-2776680615
PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2049505815
PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2049507765

From rriggs at openjdk.org  Thu Apr 17 19:34:47 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 17 Apr 2025 19:34:47 GMT
Subject: RFR: 8353214: Add testing with --enable-preview
In-Reply-To: 
References: <-PL85c8ObM1KN0uVIMTglhh6apK6fWXHFO_XdbE0UWI=.589ff6c6-b65a-48c8-807a-1960d72cac09@github.com>
 
Message-ID: 

On Thu, 17 Apr 2025 05:06:24 GMT, Chen Liang  wrote:

> Just curious, which tiers have you run with forced `--enable-preview` and discovered such incompatible tests?

I've run tiers 1-3 and have not found any incompatible tests (by that means).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24706#issuecomment-2813847009

From liach at openjdk.org  Thu Apr 17 19:36:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Apr 2025 19:36:48 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v2]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
Message-ID: 

On Thu, 17 Apr 2025 18:45:13 GMT, Brian Burkhalter  wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8354724: Address all PR comments to now

I don't see how `readString` is particularly line oriented; making `readAllLines` specific to `BufferedReader` makes sense.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2813850287

From liach at openjdk.org  Thu Apr 17 19:50:23 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Apr 2025 19:50:23 GMT
Subject: RFR: 8354899: Reduce overhead associated with type switches
In-Reply-To: 
References: 
Message-ID: <2jJ73l6h1Pv2cqDPfOT2CM5LQ-3QS40Y9KJV2jOfFqw=.536854a3-45b3-4c0b-b4c7-4bd5a3b72bb8@github.com>

On Thu, 17 Apr 2025 00:08:55 GMT, Chen Liang  wrote:

> The downcallHandle method in Linker has a complex implementation, and type switches is triggered in multiple places in that handle.
> 
> After bytestacks analysis of a simple program that links the native implementation of Class::forName0, it turns out that:
> 1. there are a few missed usages of type switch in ClassFile API
> 2. type switch can speed up generation by using explicit stack maps, as stack map gen is over 50% of the generation instructions because the switch is branch-heavy, but the frames are actually simple.
> 
> These two combined are not that significant in the overall overhead of downcallHandle, but would be helpful for other workloads.

src/java.base/share/classes/jdk/internal/classfile/impl/BlockCodeBuilderImpl.java line 78:

> 76:             return bcb.topLocal;
> 77:         }
> 78:         return findTerminal(parent).curTopLocal();

This advanced switch prevents `CodeBuilder::ifThen` or `ifThenElse` from being used in early bootstrap.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24705#discussion_r2049547487

From liach at openjdk.org  Thu Apr 17 19:50:23 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Apr 2025 19:50:23 GMT
Subject: RFR: 8354899: Reduce overhead associated with type switches
Message-ID: 

The downcallHandle method in Linker has a complex implementation, and type switches is triggered in multiple places in that handle.

After bytestacks analysis of a simple program that links the native implementation of Class::forName0, it turns out that:
1. there are a few missed usages of type switch in ClassFile API
2. type switch can speed up generation by using explicit stack maps, as stack map gen is over 50% of the generation instructions because the switch is branch-heavy, but the frames are actually simple.

These two combined are not that significant in the overall overhead of downcallHandle, but would be helpful for other workloads.

-------------

Commit messages:
 - Fix adding potentially unbound labels
 - 8354899: Reduce overhead associated with type switches

Changes: https://git.openjdk.org/jdk/pull/24705/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24705&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354899
  Stats: 82 lines in 8 files changed: 38 ins; 9 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/24705.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24705/head:pull/24705

PR: https://git.openjdk.org/jdk/pull/24705

From rriggs at openjdk.org  Thu Apr 17 20:06:46 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 17 Apr 2025 20:06:46 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v2]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
Message-ID: 

On Thu, 17 Apr 2025 19:34:13 GMT, Chen Liang  wrote:

> I don't see how `readString` is particularly line oriented; making `readAllLines` specific to `BufferedReader` makes sense.

Put another way, I don't think it makes sense to break up the higher level APIs across classes.
The buffering provided combined with the line oriented functions provides a good common place to make the methods discoverable and easy to use. YMMV

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2813903419

From lmesnik at openjdk.org  Thu Apr 17 20:10:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 17 Apr 2025 20:10:52 GMT
Subject: RFR: 8353214: Add testing with --enable-preview
In-Reply-To: <-PL85c8ObM1KN0uVIMTglhh6apK6fWXHFO_XdbE0UWI=.589ff6c6-b65a-48c8-807a-1960d72cac09@github.com>
References: <-PL85c8ObM1KN0uVIMTglhh6apK6fWXHFO_XdbE0UWI=.589ff6c6-b65a-48c8-807a-1960d72cac09@github.com>
Message-ID: 

On Thu, 17 Apr 2025 00:24:50 GMT, Leonid Mesnik  wrote:

> Added problemlists and and requires for execution tests with --enable-preview.
> 
> The --enable-preview features might significantly change VM/JDK behavior and sometimes it is useful to run tests with preview features enabled. Eventually preview features should be made default and it is expected that all tests should still work. 
> 
> The tests that are not compatible with --enable-preview, usually because of compilation mode are marked with corresponding requires tag.

A couple of failures were in tier1 and one in tier4 hotspot testing (nsk/jdi one)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24706#issuecomment-2813914722

From liach at openjdk.org  Thu Apr 17 20:45:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Apr 2025 20:45:04 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
Message-ID: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>

Perf numbers for simple main:
Linking of `Class::forName0` down from ~152 to ~83

For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
JNI: ~45
baseline panama: ~164
patch: ~103

Also see #24705.

-------------

Commit messages:
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
 - Wip work trying to speed up FFM

Changes: https://git.openjdk.org/jdk/pull/24742/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24742&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354996
  Stats: 141 lines in 7 files changed: 123 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/24742.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24742/head:pull/24742

PR: https://git.openjdk.org/jdk/pull/24742

From jlu at openjdk.org  Thu Apr 17 20:45:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 17 Apr 2025 20:45:31 GMT
Subject: RFR: 8354344: Test behavior after cut-over for future ISO 4217
 currency [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which improves the _ValidateISO4217_ Currency test by adding testing of future currencies after the transition date.
> 
> This is done by creating a patched version of Currency that replaces `System.currentTimeMillis()` calls with a mocked value equivalent to `Long.MAX_VALUE`. A module patch is then applied to supply the new Currency class files.
> 
> The mocked time behavior is tested by using the `currency.properties` override in a separate invocation.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Naoto's feedback - check patch/mocking is working via currency.properties override

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24701/files
  - new: https://git.openjdk.org/jdk/pull/24701/files/1565a986..8ab78973

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24701&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24701&range=00-01

  Stats: 34 lines in 2 files changed: 23 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/24701.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24701/head:pull/24701

PR: https://git.openjdk.org/jdk/pull/24701

From jlu at openjdk.org  Thu Apr 17 20:45:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 17 Apr 2025 20:45:31 GMT
Subject: RFR: 8354344: Test behavior after cut-over for future ISO 4217
 currency
In-Reply-To: 
References: 
 
Message-ID: <4OMcc21bk9Axp2f5FeSqmTUgZM6y85r-vmn017Z9_WM=.6878e187-d403-4810-a676-ed9006ffaa92@github.com>

On Thu, 17 Apr 2025 00:15:47 GMT, Naoto Sato  wrote:

>> Please review this PR which improves the _ValidateISO4217_ Currency test by adding testing of future currencies after the transition date.
>> 
>> This is done by creating a patched version of Currency that replaces `System.currentTimeMillis()` calls with a mocked value equivalent to `Long.MAX_VALUE`. A module patch is then applied to supply the new Currency class files.
>> 
>> The mocked time behavior is tested by using the `currency.properties` override in a separate invocation.
>
>> As the test tracks the ISO 4217 data, manual testing of this change can be done by modifying the cut-over year from 2025 to 2026 for the `CW=ANG;2025-04-01-04-00-00;XCG` entry for both the JDK and test data.
> 
> Would it be possible to use `currency.properties` file to provide a test transition, and use this logic test the validity, so that it is not a manual testing? Still it is not 100% same with the data from `currency.data`, but at least provides the transition logic validity, possibly for both simple and special currencies.

@naotoj Thanks for the idea. The latest [commit](https://github.com/openjdk/jdk/pull/24701/commits/8ab7897315294acd1777cce010bd9b037f66ef3d) supplies a custom entry in the properties file override. In the year 3000, `PK` uses the custom currency `JPZ`. Another invocation, (the second one), is added with the override passed via command line, which checks that `PK` is correctly returning `JPZ`. This indicates we have successfully mocked the time and the module patch has been applied. We do this separately from the third invocation as to not conflict with the golden ISO data.

Thus the invocations behave as follows,

1 - Test ISO data with current time + Build module patch with mocked time
2 - Check that the module patch and mocked time function correctly. (NO tests are ran).
3 - Test ISO data with mocked time

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24701#issuecomment-2813977463

From liach at openjdk.org  Thu Apr 17 20:51:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Apr 2025 20:51:10 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine [v2]
In-Reply-To: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
Message-ID: 

> When jdeps was migrated from old classfile to ClassFile API, the parsing semantic changed - error checks are now made lazily, and nested crashes from malformed signature or other problems is now latent, after a `ClassModel` instance is available. (The old error check existed only for constructing a `ClassModel`)
> 
> To address this issue, I have updated the way of iterating class files to be handler/consumer based like in the ClassFile API. This has the advantage that when one invocation of the handler fails of a `ClassFileError`, other invocations for other class files can proceed, and the exception handler has sufficient information to report a useful message indicating the source of error.
> 
> For the particular example of examining a proguard processed `dummy-scala.jar`, here is the new output of `jdeps dummy-scala.jar`:
> 
> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 59, expected an identifier: Lscala/collection/immutable/TreeMap$TreeMapBuilder.;: scala/collection/immutable/TreeMap$TreeMapBuilder.class (dummy-scala.jar)
> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 49, expected an identifier: Lscala/collection/parallel/mutable/ParArray.;: scala/collection/parallel/mutable/ParArray.class (dummy-scala.jar)
> 
> 
> Now, jdeps shows the bad class files. Inspection into the files reveal that proguard incorrectly deleted the simple class names with trailing `$`, for example, the original signature of the broken ParArray was `Lscala/collection/parallel/mutable/ParArray.ParArrayIterator$;`, so the `ParArrayIterator$` part was incorrectly dropped by proguard.
> 
> Testing: langtools/tools/jdeps.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Review remarks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24604/files
  - new: https://git.openjdk.org/jdk/pull/24604/files/e0f1eef8..7d2d5d0c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24604&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24604&range=00-01

  Stats: 26 lines in 2 files changed: 0 ins; 10 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/24604.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24604/head:pull/24604

PR: https://git.openjdk.org/jdk/pull/24604

From liach at openjdk.org  Thu Apr 17 20:51:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Apr 2025 20:51:10 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine [v2]
In-Reply-To: 
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
 
Message-ID: 

On Thu, 17 Apr 2025 16:44:02 GMT, Henry Jen  wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks
>
> src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java line 105:
> 
>> 103: 
>> 104:     protected void skipEntry(ClassFileError ex, String fileName) {
>> 105:         skippedEntries.add(String.format("%s: %s", ex.toString(), fileName));
> 
> The second parameter is not always a straightforward filename, consider to rename it, perhaps `entryPath`?

Indeed. Renamed to `entryPath`. Also adjusted this to accept `Throwable`, so we can skip an entry due to either IOException or ClassFileError.

> src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java line 237:
> 
>> 235:                               skipEntry(ex, e.toString());
>> 236:                           } catch (IOException ex) {
>> 237:                               throw new UncheckedIOException(ex);
> 
> Just to point out this was leading to ClassFileError in the old implementation, new implementation will relay the IOException, which I think is proper.

I have updated this to skip as well - if the outer structure is malformed, we should not have reached this far and would have encountered IOException earlier.

> src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java line 339:
> 
>> 337:                         });
>> 338:             } catch (UncheckedIOException ex) {
>> 339:                 throw ex.getCause();
> 
> IOException used to skip entry with message and continue, the new behavior would change. I am not certain this is behavior compatible.
> I doubt IOException would be recoverable on different entry, but it might in rare cases?

Yep, I think skipping for IOE is correct. If IOE is serious enough that no element is accessible, it should usually be thrown earlier.

> src/jdk.jdeps/share/classes/com/sun/tools/jdeps/DependencyFinder.java line 176:
> 
>> 174:         FutureTask> task = new FutureTask<>(() -> {
>> 175:             Set targets = new HashSet<>();
>> 176:             archive.reader().processClassFiles(cf -> {
> 
> I prefer the naming convention with forEach for operation to iterate through rather than have a `process` on a reader. Perhaps named like `forEachClassFile`?

Done in the update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24604#discussion_r2049625074
PR Review Comment: https://git.openjdk.org/jdk/pull/24604#discussion_r2049626124
PR Review Comment: https://git.openjdk.org/jdk/pull/24604#discussion_r2049626614
PR Review Comment: https://git.openjdk.org/jdk/pull/24604#discussion_r2049625262

From henryjen at openjdk.org  Thu Apr 17 21:06:46 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 17 Apr 2025 21:06:46 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine [v2]
In-Reply-To: 
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
 
Message-ID: 

On Thu, 17 Apr 2025 20:51:10 GMT, Chen Liang  wrote:

>> When jdeps was migrated from old classfile to ClassFile API, the parsing semantic changed - error checks are now made lazily, and nested crashes from malformed signature or other problems is now latent, after a `ClassModel` instance is available. (The old error check existed only for constructing a `ClassModel`)
>> 
>> To address this issue, I have updated the way of iterating class files to be handler/consumer based like in the ClassFile API. This has the advantage that when one invocation of the handler fails of a `ClassFileError`, other invocations for other class files can proceed, and the exception handler has sufficient information to report a useful message indicating the source of error.
>> 
>> For the particular example of examining a proguard processed `dummy-scala.jar`, here is the new output of `jdeps dummy-scala.jar`:
>> 
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 59, expected an identifier: Lscala/collection/immutable/TreeMap$TreeMapBuilder.;: scala/collection/immutable/TreeMap$TreeMapBuilder.class (dummy-scala.jar)
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 49, expected an identifier: Lscala/collection/parallel/mutable/ParArray.;: scala/collection/parallel/mutable/ParArray.class (dummy-scala.jar)
>> 
>> 
>> Now, jdeps shows the bad class files. Inspection into the files reveal that proguard incorrectly deleted the simple class names with trailing `$`, for example, the original signature of the broken ParArray was `Lscala/collection/parallel/mutable/ParArray.ParArrayIterator$;`, so the `ParArrayIterator$` part was incorrectly dropped by proguard.
>> 
>> Testing: langtools/tools/jdeps.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks

Looks good to me

-------------

Marked as reviewed by henryjen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24604#pullrequestreview-2776919222

From iklam at openjdk.org  Thu Apr 17 21:23:55 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 17 Apr 2025 21:23:55 GMT
Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking
In-Reply-To: 
References: 
Message-ID: 

On Wed, 16 Apr 2025 18:21:41 GMT, Calvin Cheung  wrote:

> This RFE allows --add-opens to be specified for AOT cache creation. AOT cache can be used during production run with --add-opens option as long as the same set of options is used during assembly phase.
> 
> Passed tiers 1 - 4 testing.

Do we have a test case where  `--add-opens` is used both at dump time and run time? That will verify that `--add-opens` at dump time is correctly processed.

If we don't have a test yet, I think we can modify the existing test to iterate this block twice: once with `--add-opens` at dump time and once without. Both iterations should allow the `setAccessible` call.

https://github.com/openjdk/jdk/blob/ad7c475fb1e23f583a33d58f0bd73ea0fb56740c/test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/AddOpens.java#L85-L105

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24695#issuecomment-2814049507

From duke at openjdk.org  Thu Apr 17 21:29:21 2025
From: duke at openjdk.org (Markus KARG)
Date: Thu, 17 Apr 2025 21:29:21 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v6]
In-Reply-To: 
References: 
Message-ID: 

> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
> 
> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
> 
> To ensure quality...
> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21730/files
  - new: https://git.openjdk.org/jdk/pull/21730/files/d2ccf42c..884e7dc1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21730&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21730&range=04-05

  Stats: 203 lines in 2 files changed: 203 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21730/head:pull/21730

PR: https://git.openjdk.org/jdk/pull/21730

From duke at openjdk.org  Thu Apr 17 21:33:58 2025
From: duke at openjdk.org (Markus KARG)
Date: Thu, 17 Apr 2025 21:33:58 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <9BsFYz2RyshIdK1liYcrQdIiJMf5yuhajoVSZ8V5LUQ=.23bc0d84-4f72-41d2-b5d1-753bc12c4e22@github.com>
References: 
 
 
 
 
 
 <9BsFYz2RyshIdK1liYcrQdIiJMf5yuhajoVSZ8V5LUQ=.23bc0d84-4f72-41d2-b5d1-753bc12c4e22@github.com>
Message-ID: 

On Wed, 16 Apr 2025 17:04:07 GMT, Jaikiran Pai  wrote:

> > IIUC then you will be fine with a test that solely tests the default implementation of CharSequence.getChars()?
> 
> Correct. And a similar separate test for `CharBuffer.getChars()` since that one too is a new default implementation method. I apologize if that wasn't clear in the discussion so far.

I now have covered `CharSequence.getChars()` and `CharBuffer.getChars()` with *separate* basic unit testing. Does this fit? ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2814062190

From smarks at openjdk.org  Thu Apr 17 21:34:54 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 17 Apr 2025 21:34:54 GMT
Subject: RFR: 8354464: Additional cleanup setting up native.encoding [v2]
In-Reply-To: <0VYRPZr5WZMV2FcWuBUQ1hXPcvUizP7mRIub1swk1jQ=.19b21b51-37ed-44cc-99d1-37e9b16dfe72@github.com>
References: 
 
 <0VYRPZr5WZMV2FcWuBUQ1hXPcvUizP7mRIub1swk1jQ=.19b21b51-37ed-44cc-99d1-37e9b16dfe72@github.com>
Message-ID: 

On Wed, 16 Apr 2025 13:20:33 GMT, Alan Bateman  wrote:

>> Stuart Marks 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:
>> 
>>  - Move asserts into platform-independent code.
>>  - Merge branch 'master' into JDK-8354464-additional-cleanup-native-encoding
>>  - Rename variables to make clear they're not used.
>>  - 8354464: Additional cleanup setting up native.encoding
>
> I've gone through this, I don't see any issues.

Sorry, @AlanBateman and @naotoj and I have been over this code a bunch of times, and I thought their reviews were sufficient.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24607#issuecomment-2814064006

From jlu at openjdk.org  Thu Apr 17 21:35:08 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 17 Apr 2025 21:35:08 GMT
Subject: RFR: 8354344: Test behavior after cut-over for future ISO 4217
 currency [v3]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which improves the _ValidateISO4217_ Currency test by adding testing of future currencies after the transition date.
> 
> This is done by creating a patched version of Currency that replaces `System.currentTimeMillis()` calls with a mocked value equivalent to `Long.MAX_VALUE`. A module patch is then applied to supply the new Currency class files.
> 
> The mocked time behavior is tested by using the `currency.properties` override in a separate invocation.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  simple/special case in check invocation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24701/files
  - new: https://git.openjdk.org/jdk/pull/24701/files/8ab78973..60cda372

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24701&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24701&range=01-02

  Stats: 9 lines in 2 files changed: 3 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24701.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24701/head:pull/24701

PR: https://git.openjdk.org/jdk/pull/24701

From bpb at openjdk.org  Thu Apr 17 21:57:04 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Apr 2025 21:57:04 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v3]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: 

> Implement the requested methods and add a test thereof.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8354724: Modify specification verbiage more or less as suggested

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/b5d82665..4fac584c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=01-02

  Stats: 16 lines in 1 file changed: 10 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728

PR: https://git.openjdk.org/jdk/pull/24728

From bpb at openjdk.org  Thu Apr 17 21:57:04 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Apr 2025 21:57:04 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v2]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
Message-ID: 

On Thu, 17 Apr 2025 19:08:52 GMT, Roger Riggs  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8354724: Address all PR comments to now
>
> src/java.base/share/classes/java/io/BufferedReader.java line 417:
> 
>> 415:      * the expression:
>> 416:      * 
{@link #lines()}.toList()

>> 417:      *
> 
> It is worth noting that if an IOException occurs, the reader and underlying stream are left in an unpredictable state?
> 
> With a normal or exceptional return should anything be said about the state of the underlying stream?
> The corresponding method on Files ensures the reader is closed (and propagates to the underlying stream).

Please see the changes in [4fac584](https://github.com/openjdk/jdk/pull/24728/commits/4fac584c5b19b3910e7a362656d2b406ad4ba189).

> src/java.base/share/classes/java/io/BufferedReader.java line 426:
> 
>> 424:      *             {@code List} is modifiable is implementation dependent,
>> 425:      *             hence not specified
>> 426:      *
> 
> Does the rationale used in Files to leaving this indeterminate apply here?
> I'd think it would be better to say its not-modifyable.
> Here its free/cheap, the Stream.toList() method creates an un-modifiableList.

Please see the changes in [4fac584](https://github.com/openjdk/jdk/pull/24728/commits/4fac584c5b19b3910e7a362656d2b406ad4ba189).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2049695645
PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2049695702

From naoto at openjdk.org  Thu Apr 17 22:11:42 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 17 Apr 2025 22:11:42 GMT
Subject: RFR: 8354344: Test behavior after cut-over for future ISO 4217
 currency [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Apr 2025 21:35:08 GMT, Justin Lu  wrote:

>> Please review this PR which improves the _ValidateISO4217_ Currency test by adding testing of future currencies after the transition date.
>> 
>> This is done by creating a patched version of Currency that replaces `System.currentTimeMillis()` calls with a mocked value equivalent to `Long.MAX_VALUE`. A module patch is then applied to supply the new Currency class files.
>> 
>> The mocked time behavior is tested by using the `currency.properties` override in a separate invocation.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simple/special case in check invocation

Good to see the future currency testing.

test/jdk/java/util/Currency/ValidateISO4217.java line 157:

> 155:     // "check" invocation only runs the main method (and not any tests) to determine if the
> 156:     // future time checking is correct
> 157:     public static void main(String[] args) {

It would probably helpful to check if the patched Currency class does exist or not. Same for the `MOCKED.TIME=true` case.

test/jdk/java/util/Currency/ValidateISO4217.java line 203:

> 201:         CodeTransform codeTransform = (codeBuilder, e) -> {
> 202:             switch (e) {
> 203:                 case InvokeInstruction i when i.name().stringValue().equals("currentTimeMillis") ->

`equalsString()` may be used. Regardless, is there a way to tell this call is indeed `System.currentTimeMillis()`? Might do that check in case a method on Currency with the same name is introduced (not likely though).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24701#pullrequestreview-2777025817
PR Review Comment: https://git.openjdk.org/jdk/pull/24701#discussion_r2049702515
PR Review Comment: https://git.openjdk.org/jdk/pull/24701#discussion_r2049704312

From bpb at openjdk.org  Thu Apr 17 22:13:06 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Apr 2025 22:13:06 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v4]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: <77Tx6RSUixNQ-PGXiNxmNnOkvWQsOnZZI-ZgisWiJsA=.7b5006d8-6c87-4d90-86d8-a6c7b5c758d1@github.com>

> Implement the requested methods and add a test thereof.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8354724: Change the test to reuse a ByteBuffer when writing the file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/4fac584c..422703fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=02-03

  Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728

PR: https://git.openjdk.org/jdk/pull/24728

From liach at openjdk.org  Thu Apr 17 22:25:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Apr 2025 22:25:46 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Apr 2025 21:29:21 GMT, Markus KARG  wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars()

The unit tests look good.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21730#pullrequestreview-2777052617

From smarks at openjdk.org  Thu Apr 17 22:32:44 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 17 Apr 2025 22:32:44 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v4]
In-Reply-To: <77Tx6RSUixNQ-PGXiNxmNnOkvWQsOnZZI-ZgisWiJsA=.7b5006d8-6c87-4d90-86d8-a6c7b5c758d1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <77Tx6RSUixNQ-PGXiNxmNnOkvWQsOnZZI-ZgisWiJsA=.7b5006d8-6c87-4d90-86d8-a6c7b5c758d1@github.com>
Message-ID: 

On Thu, 17 Apr 2025 22:13:06 GMT, Brian Burkhalter  wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8354724: Change the test to reuse a ByteBuffer when writing the file

There's a case to be made to have readString() on Reader instead of BufferedReader. The somewhat analogous method readAllBytes() is on InputStream. The bulk transferTo() method appears on both InputStream and Reader. From a practical standpoint, there are a lot of APIs in the JDK that return a Reader (not a BufferedReader) so having readString() on Reader saves the caller an extra step of wrapping it in a BufferedReader or creating a StringWriter as the destination of transferTo().

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2814135868

From iklam at openjdk.org  Thu Apr 17 22:40:46 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 17 Apr 2025 22:40:46 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Apr 2025 07:41:36 GMT, Timofei Pushkin  wrote:

>> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app.
>> 
>> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible.
>
> Timofei Pushkin has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Make RegUnregSuperTest AOTClassLinking-compatible
>  - Extend overshadowing explanation comments

Looks good to me overall. I just have a request for cleaning up `ClassListParser::check_supertype_overshadowing()`

-------------

PR Review: https://git.openjdk.org/jdk/pull/24223#pullrequestreview-2777066054

From iklam at openjdk.org  Thu Apr 17 22:40:47 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 17 Apr 2025 22:40:47 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing
 classlist to create CDS archive [v10]
In-Reply-To: 
References: 
 
 
 
Message-ID: <8ILSBp3DmQkV_JRN0Yi70XgQBVZTWoqJgPeZizKa0zQ=.f6e03e97-845c-4e14-8e7c-6252cf05873f@github.com>

On Thu, 17 Apr 2025 07:14:25 GMT, Timofei Pushkin  wrote:

>> src/hotspot/share/cds/classListParser.cpp line 517:
>> 
>>> 515:     return;
>>> 516:   }
>>> 517:   assert(!supertype->is_shared_unregistered_class(), "unregistered supertype cannot be overshadowed");
>> 
>> Does this always prevent an unregistered class to use any other unregistered class as its super type?
>> 
>> I think a better check would be here:
>> 
>> 
>>     if (!k->local_interfaces()->contains(specified_interface)) {
>> +     jio_fprintf(defaultStream::error_stream(), "Specified interface %s (id %d) is not directly implemented\n",
>> +           specified_interface->external_name(), _interfaces->at(i));
>>       print_specified_interfaces();
>>       print_actual_interfaces(k);
>> +     throw exception .....      
>> -     error("Specified interface %s (id %d) is not directly implemented",
>> -           specified_interface->external_name(), _interfaces->at(i));
>>       }
>
> Overshadowing should be checked before attempting to load the class. Otherwise if the wrongly used super has a different classfile than the specified super we may get class loading errors (see JVMS 5.3.5.3 and 5.3.5.4), e.g. if the specified super wasn't final but we try to use a final class instead of it. I'll extend the related explanation comments in the code.
> 
>> Does this always prevent an unregistered class to use any other unregistered class as its super type?
> 
> The only way I see for another class to be used instead is for the unregistered class being loaded to reference supertypes of unexpected names in its classfile. But this is an error and it will be detected as such in the C++ code you've cited. If you have any other cases in mind please share.

Sorry I didn't notice the `overshadower == supertype` check. Now I understand how it works.

However, I think the logic of the code isn't expressed in the same way as mentioned in the comments. That's why I misread it. I would suggest restructuring it like this for clarity.

Also, the opposite to "unregistered" is "built-in". We used to have a third type (classes for "registered" custom class loaders) but that has been removed, leaving us the odd terminology. Maybe we'll clean that up when more support is added to custom loaders in Leyden.

BTW, I think we should use "shadow" instead of "overshadow" for brevity.


void ClassListParser::check_supertype_overshadowing(int supertype_id, const InstanceKlass* specified_supertype, TRAPS) {
  if (!specified_supertype->is_shared_unregistered_class()) {
    const InstanceKlass* overshadower = SystemDictionaryShared::get_unregistered_class(specified_supertype->name());
    if (overshadower != nullptr) {
      // If an unregistered class U is specified to have a built-in supertype S1
      // named SN but an unregistered class S2 also named SN has already been loaded
      // S2 will be incorrectly resolved as the supertype of U instead of S1 due to
      // limitations in the loading mechanism of unregistered classes.
      // This happens very rarely and we don't support such use cases in the CDS archive.
      ResourceMark rm;
      THROW_MSG(vmSymbols::java_lang_UnsupportedOperationException(),
                err_msg("%s (id %d) has super-type %s (id %d) overshadowed by another class with the same name",
                        _class_name, _id, supertype->external_name(), supertype_id));
    }
  }
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2049723549

From liach at openjdk.org  Thu Apr 17 22:42:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Apr 2025 22:42:43 GMT
Subject: RFR: 8354899: Reduce overhead associated with type switches
In-Reply-To: 
References: 
Message-ID: 

On Thu, 17 Apr 2025 00:08:55 GMT, Chen Liang  wrote:

> The downcallHandle method in Linker has a complex implementation, and type switches is triggered in multiple places in that handle.
> 
> After bytestacks analysis of a simple program that links the native implementation of Class::forName0, it turns out that:
> 1. there are a few missed usages of type switch in ClassFile API
> 2. type switch can speed up generation by using explicit stack maps, as stack map gen is over 50% of the generation instructions because the switch is branch-heavy, but the frames are actually simple.
> 
> These two combined are not that significant in the overall overhead of downcallHandle, but would be helpful for other workloads.

Testing: tier 1-3

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24705#issuecomment-2814146206

From rriggs at openjdk.org  Thu Apr 17 22:46:42 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 17 Apr 2025 22:46:42 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v4]
In-Reply-To: <77Tx6RSUixNQ-PGXiNxmNnOkvWQsOnZZI-ZgisWiJsA=.7b5006d8-6c87-4d90-86d8-a6c7b5c758d1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <77Tx6RSUixNQ-PGXiNxmNnOkvWQsOnZZI-ZgisWiJsA=.7b5006d8-6c87-4d90-86d8-a6c7b5c758d1@github.com>
Message-ID: 

On Thu, 17 Apr 2025 22:13:06 GMT, Brian Burkhalter  wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8354724: Change the test to reuse a ByteBuffer when writing the file

I'm fine with moving `readString` to `Reader`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2814150427

From bpb at openjdk.org  Thu Apr 17 22:58:40 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Apr 2025 22:58:40 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v4]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <77Tx6RSUixNQ-PGXiNxmNnOkvWQsOnZZI-ZgisWiJsA=.7b5006d8-6c87-4d90-86d8-a6c7b5c758d1@github.com>
 
Message-ID: 

On Thu, 17 Apr 2025 22:43:59 GMT, Roger Riggs  wrote:

> I'm fine with moving `readString` to `Reader`.

Given that [Reader.read(char[])](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/Reader.html#read(char[])) exists, this should be a trivial change, implementation-wise.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2814167072

From ccheung at openjdk.org  Thu Apr 17 22:59:59 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 17 Apr 2025 22:59:59 GMT
Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking [v2]
In-Reply-To: 
References: 
Message-ID: 

> This RFE allows --add-opens to be specified for AOT cache creation. AOT cache can be used during production run with --add-opens option as long as the same set of options is used during assembly phase.
> 
> Passed tiers 1 - 4 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  cleanup testcase

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24695/files
  - new: https://git.openjdk.org/jdk/pull/24695/files/4fa5f8fb..658a895b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24695&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24695&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24695.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24695/head:pull/24695

PR: https://git.openjdk.org/jdk/pull/24695

From almatvee at openjdk.org  Thu Apr 17 23:01:40 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 17 Apr 2025 23:01:40 GMT
Subject: RFR: 8354985: Add unit tests for Executor class from jpackage test
 lib
In-Reply-To: 
References: 
Message-ID: 

On Thu, 17 Apr 2025 18:53:16 GMT, Alexey Semenyuk  wrote:

> - Add tests covering command output handling in the Executor class
>  - Fix revealed bugs
>  - Add a couple of `Executor.of()` convenience methods
> 
> The test is implemented in a way that it will remain mostly unchanged when Executor supports disabling of stderr and stdout streams.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24737#pullrequestreview-2777094666

From ccheung at openjdk.org  Thu Apr 17 23:02:49 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 17 Apr 2025 23:02:49 GMT
Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Apr 2025 21:21:22 GMT, Ioi Lam  wrote:

> Do we have a test case where `--add-opens` is used both at dump time and run time? That will verify that `--add-opens` at dump time is correctly processed.
> 

Yes, the new test `AddopensOption.java` uses the `--add-opens` both at dump time and run time.
I have done some minor cleanup on the test, please review the new version.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24695#issuecomment-2814171015

From jlu at openjdk.org  Thu Apr 17 23:06:04 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 17 Apr 2025 23:06:04 GMT
Subject: RFR: 8354344: Test behavior after cut-over for future ISO 4217
 currency [v4]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which improves the _ValidateISO4217_ Currency test by adding testing of future currencies after the transition date.
> 
> This is done by creating a patched version of Currency that replaces `System.currentTimeMillis()` calls with a mocked value equivalent to `Long.MAX_VALUE`. A module patch is then applied to supply the new Currency class files.
> 
> The mocked time behavior is tested by using the `currency.properties` override in a separate invocation.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Naoto review - check instruction owner. check module patch files exist

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24701/files
  - new: https://git.openjdk.org/jdk/pull/24701/files/60cda372..c58f11f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24701&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24701&range=02-03

  Stats: 22 lines in 1 file changed: 18 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24701.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24701/head:pull/24701

PR: https://git.openjdk.org/jdk/pull/24701

From jlu at openjdk.org  Thu Apr 17 23:06:05 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 17 Apr 2025 23:06:05 GMT
Subject: RFR: 8354344: Test behavior after cut-over for future ISO 4217
 currency [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 17 Apr 2025 22:05:31 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   simple/special case in check invocation
>
> test/jdk/java/util/Currency/ValidateISO4217.java line 203:
> 
>> 201:         CodeTransform codeTransform = (codeBuilder, e) -> {
>> 202:             switch (e) {
>> 203:                 case InvokeInstruction i when i.name().stringValue().equals("currentTimeMillis") ->
> 
> `equalsString()` may be used. Regardless, is there a way to tell this call is indeed `System.currentTimeMillis()`? Might do that check in case a method on Currency with the same name is introduced (not likely though).

Yes, we can check the owner name is _java/lang/System_. Addressed your other comment as well in https://github.com/openjdk/jdk/pull/24701/commits/c58f11f2affa19267aa2416bcff10f842c13d871.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24701#discussion_r2049739614

From bpb at openjdk.org  Thu Apr 17 23:07:35 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Apr 2025 23:07:35 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v5]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: 

> Implement the requested methods and add a test thereof.

Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:

 - 8354724: Increment copyright year in Reader
 - 8354724: Move readString from BufferedReader to Reader

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/422703fe..8b0b9238

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=03-04

  Stats: 72 lines in 2 files changed: 35 ins; 36 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728

PR: https://git.openjdk.org/jdk/pull/24728

From bpb at openjdk.org  Thu Apr 17 23:07:36 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Apr 2025 23:07:36 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v4]
In-Reply-To: <77Tx6RSUixNQ-PGXiNxmNnOkvWQsOnZZI-ZgisWiJsA=.7b5006d8-6c87-4d90-86d8-a6c7b5c758d1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 <77Tx6RSUixNQ-PGXiNxmNnOkvWQsOnZZI-ZgisWiJsA=.7b5006d8-6c87-4d90-86d8-a6c7b5c758d1@github.com>
Message-ID: 

On Thu, 17 Apr 2025 22:13:06 GMT, Brian Burkhalter  wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8354724: Change the test to reuse a ByteBuffer when writing the file

I moved `readString` to `Reader` but left its regression test in `java/io/BufferedReader/ReadAll.java`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2814176144

From duke at openjdk.org  Thu Apr 17 23:20:54 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 17 Apr 2025 23:20:54 GMT
Subject: RFR: 8077587: BigInteger Roots [v8]
In-Reply-To: 
References: 
Message-ID: <0IMWfrQMlUhMAg0urgql9K60lI9ofHTchdg3ECxFPG8=.e8619409-f934-4c44-9651-2c03b57d9257@github.com>

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Format code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/1f5a9b48..b6c33205

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=06-07

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From asemenyuk at openjdk.org  Thu Apr 17 23:40:52 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 17 Apr 2025 23:40:52 GMT
Subject: Integrated: 8354985: Add unit tests for Executor class from jpackage
 test lib
In-Reply-To: 
References: 
Message-ID: 

On Thu, 17 Apr 2025 18:53:16 GMT, Alexey Semenyuk  wrote:

> - Add tests covering command output handling in the Executor class
>  - Fix revealed bugs
>  - Add a couple of `Executor.of()` convenience methods
> 
> The test is implemented in a way that it will remain mostly unchanged when Executor supports disabling of stderr and stdout streams.

This pull request has now been integrated.

Changeset: 38f138bc
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/38f138bc22ae705e8e09f75fe6bac4bb470dc29b
Stats:     393 lines in 2 files changed: 380 ins; 6 del; 7 mod

8354985: Add unit tests for Executor class from jpackage test lib

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/24737

From duke at openjdk.org  Fri Apr 18 00:09:27 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 18 Apr 2025 00:09:27 GMT
Subject: RFR: 8077587: BigInteger Roots [v9]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Correct left shift if shift is zero

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/b6c33205..5d971fac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From asemenyuk at openjdk.org  Fri Apr 18 00:12:57 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 18 Apr 2025 00:12:57 GMT
Subject: RFR: 8354988: Separate stderr and stdout in Executor class from
 jpackage test lib
Message-ID: 

Rework Executor class from jpackage test lib to support separate configuration of stdout and stderr streams handling:
 - New `Executor.discardStdout(boolean)` and `Executor.discardStderr(boolean)` methods enable/disable stdout and stderr streams, respectively;
 - New `Executor.Result.stdout()` accesses saved stdout stream;
 - New `Executor.Result.stderr()` accesses saved stderr stream;
 - `Executor.Result.getOutput()` returns merged stdout and stderr streams. Contents of the stdout go first, contents of the stderr follow;
 - New `JPackageCommand.discardStdout(boolean)` and `JPackageCommand.discardStderr(boolean)` methods enable/disable stdout and stderr streams produced by jpackage, respectively.

Additionally:
 - Streamline `BasicTest.testErrorsAlwaysPrinted()`;
 - Fix WindowsHelper and Win8301247Test as they stopped working as expected due to reordering the contents of stdout and stderr streams in the merged stream returned by `Executor.Result.getOutput()`.

-------------

Commit messages:
 - Fix Win8301247Test to make it log exception if any occurs after the laucnher is started. Prior this change test just hang with no output.
 - Add JPackageCommand.discardStdout(boolean) and JPackageCommand.discardStderr(boolean). Better BasicTest.testErrorsAlwaysPrinted()
 - Add Executor.discardStdout() and Executor.discardStderr(). stsdout and st?err are captured individually and dumped sequentially (no stderr redirection into stdout any more for process builder). Bugfix WindowsHelper.findAppLauncherPIDs() that relied on specific order or merged stderr and stdout.

Changes: https://git.openjdk.org/jdk/pull/24745/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24745&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354988
  Stats: 659 lines in 7 files changed: 488 ins; 58 del; 113 mod
  Patch: https://git.openjdk.org/jdk/pull/24745.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24745/head:pull/24745

PR: https://git.openjdk.org/jdk/pull/24745

From asemenyuk at openjdk.org  Fri Apr 18 00:12:57 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 18 Apr 2025 00:12:57 GMT
Subject: RFR: 8354988: Separate stderr and stdout in Executor class from
 jpackage test lib
In-Reply-To: 
References: 
Message-ID: 

On Thu, 17 Apr 2025 23:47:09 GMT, Alexey Semenyuk  wrote:

> Rework Executor class from jpackage test lib to support separate configuration of stdout and stderr streams handling:
>  - New `Executor.discardStdout(boolean)` and `Executor.discardStderr(boolean)` methods enable/disable stdout and stderr streams, respectively;
>  - New `Executor.Result.stdout()` accesses saved stdout stream;
>  - New `Executor.Result.stderr()` accesses saved stderr stream;
>  - `Executor.Result.getOutput()` returns merged stdout and stderr streams. Contents of the stdout go first, contents of the stderr follow;
>  - New `JPackageCommand.discardStdout(boolean)` and `JPackageCommand.discardStderr(boolean)` methods enable/disable stdout and stderr streams produced by jpackage, respectively.
> 
> Additionally:
>  - Streamline `BasicTest.testErrorsAlwaysPrinted()`;
>  - Fix WindowsHelper and Win8301247Test as they stopped working as expected due to reordering the contents of stdout and stderr streams in the merged stream returned by `Executor.Result.getOutput()`.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24745#issuecomment-2814231053

From bpb at openjdk.org  Fri Apr 18 01:05:04 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 18 Apr 2025 01:05:04 GMT
Subject: RFR: 8354450: Using a File with a path containing a trailing space
 should fail when alternative data streams are disabled (win) [v2]
In-Reply-To: <7LDV_FtSki03-PTPsSoobe3N-SbtcjVKzf933HBuFoQ=.474914b7-beda-4f80-8655-c0523bd23a87@github.com>
References: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
 
 <1EKMYPzdR0EfG8v9_hauG3wPMw0_cRATLZlg0LbE4ps=.049a55bc-797a-4eb4-9b4a-f20b02cafbe4@github.com>
 
 <7LDV_FtSki03-PTPsSoobe3N-SbtcjVKzf933HBuFoQ=.474914b7-beda-4f80-8655-c0523bd23a87@github.com>
Message-ID: 

On Wed, 16 Apr 2025 17:43:58 GMT, Alan Bateman  wrote:

>> I am not sure what you mean here as file paths _can_ contain (s) space(s).
>
> The question is about directories in the path that end with space. So yes, the file path may contain spaces but the proposed check is only looking at the end last element.

>From experimentation with C++ code is VS, it appears that `CreateDirectoryW` will create a directory with either a leading or trailing space in its name, whereas `createFileW` will create a file with a leading space in its name, but a trailing space is trimmed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24635#discussion_r2049805179

From duke at openjdk.org  Fri Apr 18 01:36:10 2025
From: duke at openjdk.org (erifan)
Date: Fri, 18 Apr 2025 01:36:10 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> This patch optimizes the following patterns:
> For integer types:
> 
> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>     => (VectorMaskCmp src1 src2 ncond)
> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>     => (VectorMaskCmp src1 src2 ncond)
> 
> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond.
> 
> For float and double types:
> 
> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
> 
> cond can be eq or ne.
> 
> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`:
> 
> Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
> testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
> testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
> testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
> testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
> testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
> testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
> testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
> testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
> testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
> testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4714008.434	1681.10365	1.41
> testCompareGTMaskNotByte	ops/s	7910823.674	2993.367032	10245063.58	9774.75138	1.29
> testCompareGTMaskNotInt		ops/s	1673393.928	3153.099431	2353654.521	1190.848583	1.4
> testCompareGTMaskNotLong	ops/s	849405.9159	2432.858159	1177952.041	359.96413	1.38
> testCompareGTMaskNotShort	ops/s	3339509.141	3339.976585	4711442.496	2673.364893	1.41
> testCompareLEMaskNotByte	ops/s	7911340.004	3114.69191	10231626.5	27134.20035	1.29
> testCompareLEMaskNotInt		ops/s	1675812.113	1340.969885	2353255.341	1452.4522	1.4
> testCompareLEMaskNotLong	ops/s	848862.8036	6564.841731	1177763.623	539.290106	1.38
> testCompareLEMaskNotShort	ops/s	3324951.54	2380.29473	4712116.251	1544.559684	1.41
> testCompareLTMaskNotByte	ops/s	7910390.844	2630.861436	10239567.69	6487.441672	1.29
> testCompareLTMaskNotInt		ops/s	1672180.09	995.238142	2353757.863	853.774734	1.4
> testCompareLTMaskNotLong	ops/s	856502.26...

erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into JDK-8354242
 - 8354242: VectorAPI: combine vector not operation with compare
   
   This patch optimizes the following patterns:
   For integer types:
   ```
   (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
       => (VectorMaskCmp src1 src2 ncond)
   (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
       => (VectorMaskCmp src1 src2 ncond)
   ```
   cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
   negative comparison of cond.
   
   For float and double types:
   ```
   (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
       => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
   (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
       => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
   ```
   cond can be eq or ne.
   
   Benchmarks on Nvidia Grace machine with 128-bit SVE2:
   With option `-XX:UseSVE=2`:
   ```
   Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
   testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
   testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
   testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
   testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
   testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
   testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
   testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
   testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
   testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
   testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4714008.434	1681.10365	1.41
   testCompareGTMaskNotByte	ops/s	7910823.674	2993.367032	10245063.58	9774.75138	1.29
   testCompareGTMaskNotInt		ops/s	1673393.928	3153.099431	2353654.521	1190.848583	1.4
   testCompareGTMaskNotLong	ops/s	849405.9159	2432.858159	1177952.041	359.96413	1.38
   testCompareGTMaskNotShort	ops/s	3339509.141	3339.976585	4711442.496	2673.364893	1.41
   testCompareLEMaskNotByte	ops/s	7911340.004	3114.69191	10231626.5	27134.20035	1.29
   testCompareLEMaskNotInt		ops/s	1675812.113	1340.969885	2353255.341	1452.4522	1.4
   testCompareLEMaskNotLong	ops/s	848862.8036	6564.841731	1177763.623	539.290106	1.38
   testCompareLEMaskNotShort	ops/s	3324951.54	2380.29473	4712116.251	1544.559684	1.41
   testCompareLTMaskNotByte	ops/s	7910390.844	2630.861436	10239567.69	6487.441672	1.29
   testCompareLTMaskNotInt		ops/s	1672180.09	995.238142	2353757.863	853.774734	1.4
   testCompareLTMaskNotLong	ops/s	856502.2695	12276.82851	1177671.815	496.723302	1.37
   testCompareLTMaskNotShort	ops/s	3325798.025	2412.702501	4711554.181	1779.302112	1.41
   testCompareNEMaskNotByte	ops/s	7910002.518	2771.82477	10245315.33	16321.93935	1.29
   testCompareNEMaskNotDouble	ops/s	863754.6022	523.140788	1179133.982	476.572178	1.36
   testCompareNEMaskNotFloat	ops/s	1723321.883	2598.484803	2358492.186	877.1401	1.36
   testCompareNEMaskNotInt		ops/s	1670288.841	751.774826	2354158.125	835.720163	1.4
   testCompareNEMaskNotLong	ops/s	836327.6835	410.525466	1178178.825	308.757932	1.4
   testCompareNEMaskNotShort	ops/s	3327815.841	1511.978763	4711379.136	2336.505531	1.41
   testCompareUGEMaskNotByte	ops/s	7906699.024	3200.936474	10253843.74	15067.59401	1.29
   testCompareUGEMaskNotInt	ops/s	1674003.923	3287.191727	2353340.666	951.381021	1.4
   testCompareUGEMaskNotLong	ops/s	852424.5562	8920.408939	1177943.609	389.6621	1.38
   testCompareUGEMaskNotShort	ops/s	3327255.858	1584.885143	4711622.355	1247.215277	1.41
   testCompareUGTMaskNotByte	ops/s	7909249.189	4435.283667	10245541.34	10993.34739	1.29
   testCompareUGTMaskNotInt	ops/s	1693713.433	20650.00213	2353153.787	1055.343846	1.38
   testCompareUGTMaskNotLong	ops/s	851022.3395	7079.065268	1177910.677	538.604598	1.38
   testCompareUGTMaskNotShort	ops/s	3327236.988	1616.886789	4711209.865	3098.494145	1.41
   testCompareULEMaskNotByte	ops/s	7909350.825	3251.262342	10261449.03	7273.831341	1.29
   testCompareULEMaskNotInt	ops/s	1672350.925	1545.304304	2353231.755	914.231193	1.4
   testCompareULEMaskNotLong	ops/s	853349.4765	9804.906913	1177967.254	435.044367	1.38
   testCompareULEMaskNotShort	ops/s	3325757.891	1555.062257	4712873.187	1650.986905	1.41
   testCompareULTMaskNotByte	ops/s	7912218.621	2633.477744	10242095.98	21921.39902	1.29
   testCompareULTMaskNotInt	ops/s	1673994.849	2672.507666	2353449.22	946.105757	1.4
   testCompareULTMaskNotLong	ops/s	849032.5868	10406.06689	1177586.047	506.541456	1.38
   testCompareULTMaskNotShort	ops/s	3328062.026	1892.991844	4713247.216	1855.983724	1.41
   
   ```
   With option `-XX:UseSVE=0`:
   ```
   Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
   testCompareEQMaskNotByte	ops/s	7895961.919	72712.90804	7746493.731	71481.92938	0.98
   testCompareEQMaskNotDouble	ops/s	789811.0455	384.493088	766473.7994	2216.581793	0.97
   testCompareEQMaskNotFloat	ops/s	1806305.818	638.010451	1819616.613	3295.38958	1
   testCompareEQMaskNotInt		ops/s	1815820.144	1225.336135	1849538.401	766.29902	1.01
   testCompareEQMaskNotLong	ops/s	807336.492	335.451807	792732.9483	277.954432	0.98
   testCompareEQMaskNotShort	ops/s	4818266.38	1927.862665	4668903.001	1922.782715	0.96
   testCompareGEMaskNotByte	ops/s	7818439.678	75374.97739	16498003.98	41440.49653	2.11
   testCompareGEMaskNotInt		ops/s	1815159.05	1090.912209	2372095.779	1664.397112	1.3
   testCompareGEMaskNotLong	ops/s	804324.5575	2301.686878	927919.8507	371.766719	1.15
   testCompareGEMaskNotShort	ops/s	4818966.563	2443.643652	5385561.038	29558.37423	1.11
   testCompareGTMaskNotByte	ops/s	7893406.157	82687.74264	16470663.2	22165.55812	2.08
   testCompareGTMaskNotInt		ops/s	1815316.812	915.894106	2370447.198	655.016338	1.3
   testCompareGTMaskNotLong	ops/s	807019.456	526.525482	928079.0541	330.582693	1.15
   testCompareGTMaskNotShort	ops/s	4820552.881	1684.247747	5355902.93	5893.2915	1.11
   testCompareLEMaskNotByte	ops/s	7816263.323	79560.0015	16473621.19	56688.99585	2.1
   testCompareLEMaskNotInt		ops/s	1814915.724	926.998625	2368790.306	932.594778	1.3
   testCompareLEMaskNotLong	ops/s	806483.9	935.718082	928110.9074	407.096695	1.15
   testCompareLEMaskNotShort	ops/s	4813660.241	6817.870509	5357107.852	10061.47975	1.11
   testCompareLTMaskNotByte	ops/s	7838948.962	69136.4504	16424405.96	24464.75469	2.09
   testCompareLTMaskNotInt		ops/s	1815056.833	1187.6453	2369892.187	1103.819634	1.3
   testCompareLTMaskNotLong	ops/s	806602.1804	287.923365	928346.4118	617.682824	1.15
   testCompareLTMaskNotShort	ops/s	4817940.643	2767.1509	5372537.84	15397.47169	1.11
   testCompareNEMaskNotByte	ops/s	9078493.798	4630.339307	16484348.42	18925.88346	1.81
   testCompareNEMaskNotDouble	ops/s	661769.6272	398.712981	926763.5839	1808.843788	1.4
   testCompareNEMaskNotFloat	ops/s	1570527.252	563.642144	2312425.678	1815.844846	1.47
   testCompareNEMaskNotInt		ops/s	1619146.58	626.793854	2369711.543	942.330478	1.46
   testCompareNEMaskNotLong	ops/s	680201.5381	2252.836482	927808.6147	414.917863	1.36
   testCompareNEMaskNotShort	ops/s	3763508.054	3622.560798	5367808.015	8591.466599	1.42
   testCompareUGEMaskNotByte	ops/s	7886373.129	75917.74675	16480928.93	27524.31005	2.08
   testCompareUGEMaskNotInt	ops/s	1815636.832	750.036241	2369683.015	901.609404	1.3
   testCompareUGEMaskNotLong	ops/s	806862.5826	287.819616	928001.4394	361.063837	1.15
   testCompareUGEMaskNotShort	ops/s	4820581.361	2098.537435	5375854.248	25619.40165	1.11
   testCompareUGTMaskNotByte	ops/s	7891591.465	96614.93542	16410405.93	15012.37096	2.07
   testCompareUGTMaskNotInt	ops/s	1814871.179	662.825588	2371325.903	1170.491164	1.3
   testCompareUGTMaskNotLong	ops/s	804013.7658	2240.534209	928062.2169	531.306897	1.15
   testCompareUGTMaskNotShort	ops/s	4818150.337	3051.717685	5381449.337	21212.34187	1.11
   testCompareULEMaskNotByte	ops/s	7831540.628	81306.67253	16495250.78	38682.19675	2.1
   testCompareULEMaskNotInt	ops/s	1814484.14	687.860656	2369265.075	940.609586	1.3
   testCompareULEMaskNotLong	ops/s	807780.5749	769.876816	927538.0732	1278.267724	1.14
   testCompareULEMaskNotShort	ops/s	4817437.42	5141.336541	5356183.359	7015.608124	1.11
   testCompareULTMaskNotByte	ops/s	7849078.225	56753.59764	16395975.27	34043.67295	2.08
   testCompareULTMaskNotInt	ops/s	1814328.226	2697.219111	2370700.47	1991.841988	1.3
   testCompareULTMaskNotLong	ops/s	807166.8197	253.061506	927926.2803	252.933462	1.14
   testCompareULTMaskNotShort	ops/s	4821098.216	1625.959044	5348980.243	4100.768121	1.1
   ```
   
   Benchmarks on AMD EPYC 9124 16-Core Processor:
   With option `-XX:UseAVX=3`:
   ```
   Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
   testCompareEQMaskNotByte	ops/s	16607323.35	1233692.631	18381557.66	1163201.522	1.1
   testCompareEQMaskNotDouble	ops/s	2114285.245	58782.2534	2959946.353	43016.0445	1.39
   testCompareEQMaskNotFloat	ops/s	4480874.437	89975.29074	6960151.436	64799.143	1.55
   testCompareEQMaskNotInt		ops/s	4370906.91	51784.80889	6856955.043	313858.5504	1.56
   testCompareEQMaskNotLong	ops/s	2080065.895	26762.06732	2939142.143	67179.05314	1.41
   testCompareEQMaskNotShort	ops/s	7968282.563	210437.2781	12701214.56	473152.6407	1.59
   testCompareGEMaskNotByte	ops/s	18419141.89	473408.9451	19880059.68	321638.0397	1.07
   testCompareGEMaskNotInt		ops/s	4419015.62	77352.98633	7037639.227	151066.0383	1.59
   testCompareGEMaskNotLong	ops/s	2147982.48	49227.42782	3000275.928	39298.75344	1.39
   testCompareGEMaskNotShort	ops/s	8469039.613	17833.19707	12288229.49	244317.8812	1.45
   testCompareGTMaskNotByte	ops/s	18728997.5	468328.8358	20544730.05	392264.6466	1.09
   testCompareGTMaskNotInt		ops/s	4510009.705	78812.57357	7364629.942	70970.78473	1.63
   testCompareGTMaskNotLong	ops/s	2124104.969	40917.89257	2953536.279	35199.19687	1.39
   testCompareGTMaskNotShort	ops/s	8690557.621	311534.1159	12344017.51	457931.8741	1.42
   testCompareLEMaskNotByte	ops/s	17758400.53	478383.4945	19209183.26	1143297.241	1.08
   testCompareLEMaskNotInt		ops/s	4363664.862	43443.18063	7054093.064	78141.11476	1.61
   testCompareLEMaskNotLong	ops/s	2068632.213	29844.78023	2954766.412	50667.22502	1.42
   testCompareLEMaskNotShort	ops/s	8637608.548	183538.5511	12719010.27	473568.8825	1.47
   testCompareLTMaskNotByte	ops/s	14406138.95	423105.0163	17292417.96	371386.9689	1.2
   testCompareLTMaskNotInt		ops/s	4546707.266	131977.3144	7040483.394	213590.4657	1.54
   testCompareLTMaskNotLong	ops/s	2123277.356	47243.21499	2848720.442	58896.97045	1.34
   testCompareLTMaskNotShort	ops/s	7570169.363	649873.6295	11945383.75	988276.5955	1.57
   testCompareNEMaskNotByte	ops/s	18274529.55	683396.7384	19081938.8	1118739.778	1.04
   testCompareNEMaskNotDouble	ops/s	2112533.61	43295.50012	2912115.441	78189.51083	1.37
   testCompareNEMaskNotFloat	ops/s	4628683.814	93817.07362	6967208.729	145135.8544	1.5
   testCompareNEMaskNotInt		ops/s	4470900.214	75974.50842	7286913.662	116328.5277	1.62
   testCompareNEMaskNotLong	ops/s	2134091.061	46377.94061	2934667.477	81675.46021	1.37
   testCompareNEMaskNotShort	ops/s	8790384.287	396161.8599	13076858.35	286272.1155	1.48
   testCompareUGEMaskNotByte	ops/s	18009150.9	660803.8886	17551258.33	1667014.843	0.97
   testCompareUGEMaskNotInt	ops/s	4442928.74	83190.81019	6854088.277	329008.8901	1.54
   testCompareUGEMaskNotLong	ops/s	2088357.736	71696.24791	2973202.26	63278.78974	1.42
   testCompareUGEMaskNotShort	ops/s	8348624.02	116562.7876	12832250.78	546869.3006	1.53
   testCompareUGTMaskNotByte	ops/s	17871101.25	800199.6321	19902619.81	214003.3262	1.11
   testCompareUGTMaskNotInt	ops/s	4088304.421	137797.9723	7135454.33	124553.651	1.74
   testCompareUGTMaskNotLong	ops/s	2070610.42	19881.82182	2991536.365	36260.60767	1.44
   testCompareUGTMaskNotShort	ops/s	8637099.341	155822.1608	12756579.77	186068.199	1.47
   testCompareULEMaskNotByte	ops/s	17940901.36	1258029.364	18932484.94	694554.6305	1.05
   testCompareULEMaskNotInt	ops/s	4369177.511	74982.31936	6392773.082	550171.2266	1.46
   testCompareULEMaskNotLong	ops/s	2135905.761	43693.63178	2877579.631	41651.56289	1.34
   testCompareULEMaskNotShort	ops/s	8607710.544	132655.1676	12446370.04	441718.3035	1.44
   testCompareULTMaskNotByte	ops/s	17409912.23	1033204.537	20607479.99	362000.5056	1.18
   testCompareULTMaskNotInt	ops/s	4386455.9	119192.1635	6920123.264	186158.2845	1.57
   testCompareULTMaskNotLong	ops/s	2064995.149	38622.2734	2988343.589	39037.90006	1.44
   testCompareULTMaskNotShort	ops/s	8642182.752	230919.2442	13029582.09	437101.4923	1.5
   ```
   
   The small amount of performance degradation is due to test fluctuations.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24674/files
  - new: https://git.openjdk.org/jdk/pull/24674/files/1f3c5899..1b9c3b36

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=00-01

  Stats: 10943 lines in 221 files changed: 9732 ins; 611 del; 600 mod
  Patch: https://git.openjdk.org/jdk/pull/24674.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24674/head:pull/24674

PR: https://git.openjdk.org/jdk/pull/24674

From iklam at openjdk.org  Fri Apr 18 01:44:52 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 18 Apr 2025 01:44:52 GMT
Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 17 Apr 2025 23:00:25 GMT, Calvin Cheung  wrote:

> > Do we have a test case where `--add-opens` is used both at dump time and run time? That will verify that `--add-opens` at dump time is correctly processed.
> 
> Yes, the new test `AddopensOption.java` uses the `--add-opens` both at dump time and run time. I have done some minor cleanup on the test, please review the new version.

AddopensOption.java only checks if the --add-opens is accepted. It doesn't check if the option has any effect. I think it's better to run `TEST_MODULE1` to make sure that `setAccessible` can be called without throwing an exception. That will verify that the option has achieved the intended effect.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24695#issuecomment-2814318147

From xgong at openjdk.org  Fri Apr 18 01:48:51 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 18 Apr 2025 01:48:51 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v5]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Thu, 17 Apr 2025 18:08:21 GMT, Vladimir Ivanov  wrote:

>> Please see the `addr` definition code in https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/vectorIntrinsics.cpp#L1877 . If queried `addr` returns `nullptr` for 256-bit vectors, and the arch supports scalable vector, then the `addr` will be assigned to the scalable ones.
>
> Ah, ok. Thanks for the pointer. I aligned lookup logic with existing behavior. 
> 
> I'd like to double-check one things: is it fine to use scalable vector variants for fixed-sized vector shapes of smaller size without any explicit masking/stripping of upper vector part?

Yes, it's fine for lanewise oeprations. For others like cross-lanes, stores and other operations, we will generate a predicate to strip the upper vector part. The op list that need the masking are listed here: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/aarch64_vector.ad#L280

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2049872110

From xgong at openjdk.org  Fri Apr 18 01:51:55 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 18 Apr 2025 01:51:55 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Apr 2025 18:03:47 GMT, Vladimir Ivanov  wrote:

>> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
>> 
>> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
>> 
>> The patch consists of the following parts:
>>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
>> 
>> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
>> 
>> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
>> 
>> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
>> 
>> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
>> 
>> Thanks!
>
> Vladimir Ivanov 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 24 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into vector.math.01.java
>  - RVV and SVE adjustments
>  - fix broken merge
>  - Merge branch 'master' into vector.math.01.java
>  - Fix debugName handling
>  - Merge branch 'master' into vector.math.01.java
>  - RVV and SVE adjustments
>  - Merge branch 'master' into vector.math.01.java
>  - Fix windows-aarch64 build failure
>  - features_string -> cpu_info_string
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/c92b982b...88eacc48

Looks good to me. Thanks for your updating!

-------------

Marked as reviewed by xgong (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24462#pullrequestreview-2777322105

From almatvee at openjdk.org  Fri Apr 18 01:52:47 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 18 Apr 2025 01:52:47 GMT
Subject: RFR: 8354988: Separate stderr and stdout in Executor class from
 jpackage test lib
In-Reply-To: 
References: 
Message-ID: 

On Thu, 17 Apr 2025 23:47:09 GMT, Alexey Semenyuk  wrote:

> Rework Executor class from jpackage test lib to support separate configuration of stdout and stderr streams handling:
>  - New `Executor.discardStdout(boolean)` and `Executor.discardStderr(boolean)` methods enable/disable stdout and stderr streams, respectively;
>  - New `Executor.Result.stdout()` accesses saved stdout stream;
>  - New `Executor.Result.stderr()` accesses saved stderr stream;
>  - `Executor.Result.getOutput()` returns merged stdout and stderr streams. Contents of the stdout go first, contents of the stderr follow;
>  - New `JPackageCommand.discardStdout(boolean)` and `JPackageCommand.discardStderr(boolean)` methods enable/disable stdout and stderr streams produced by jpackage, respectively.
> 
> Additionally:
>  - Streamline `BasicTest.testErrorsAlwaysPrinted()`;
>  - Fix WindowsHelper and Win8301247Test as they stopped working as expected due to reordering the contents of stdout and stderr streams in the merged stream returned by `Executor.Result.getOutput()`.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24745#pullrequestreview-2777331746

From swen at openjdk.org  Fri Apr 18 02:28:44 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 18 Apr 2025 02:28:44 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v5]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
Message-ID: 

On Thu, 17 Apr 2025 23:07:35 GMT, Brian Burkhalter  wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8354724: Increment copyright year in Reader
>  - 8354724: Move readString from BufferedReader to Reader

src/java.base/share/classes/java/io/Reader.java line 424:

> 422:         int n;
> 423:         while ((n = read(str)) != -1) {
> 424:             result.append(str, 0, n);

If the characters in the Reader are always Latin1, this process will convert the UTF16 char[] to the LATIN1 encoded byte[] value in the StringBuilder every time, which will cause unnecessary performance overhead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2049918157

From swen at openjdk.org  Fri Apr 18 02:35:42 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 18 Apr 2025 02:35:42 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v5]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
Message-ID: 

On Fri, 18 Apr 2025 02:26:10 GMT, Shaojin Wen  wrote:

>> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8354724: Increment copyright year in Reader
>>  - 8354724: Move readString from BufferedReader to Reader
>
> src/java.base/share/classes/java/io/Reader.java line 424:
> 
>> 422:         int n;
>> 423:         while ((n = read(str)) != -1) {
>> 424:             result.append(str, 0, n);
> 
> If the characters in the Reader are always Latin1, this process will convert the UTF16 char[] to the LATIN1 encoded byte[] value in the StringBuilder every time, which will cause unnecessary performance overhead.

We need to provide a StringBuilder that creates a coder of UTF16 to avoid the unnecessary UTF16 to LATIN1 conversion overhead here. 

If we do not want to add a new public method, we can add an internal method and expose it through JLA for use here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2049921890

From liach at openjdk.org  Fri Apr 18 02:48:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Apr 2025 02:48:48 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v5]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
 
Message-ID: 

On Fri, 18 Apr 2025 02:32:39 GMT, Shaojin Wen  wrote:

>> src/java.base/share/classes/java/io/Reader.java line 424:
>> 
>>> 422:         int n;
>>> 423:         while ((n = read(str)) != -1) {
>>> 424:             result.append(str, 0, n);
>> 
>> If the characters in the Reader are always Latin1, this process will convert the UTF16 char[] to the LATIN1 encoded byte[] value in the StringBuilder every time, which will cause unnecessary performance overhead.
>
> We need to provide a StringBuilder that creates a coder of UTF16 to avoid the unnecessary UTF16 to LATIN1 conversion overhead here. 
> 
> If we do not want to add a new public method, we can add an internal method and expose it through JLA for use here.

`Reader` by specification works on `char`, so I think this is fine. Even if a StringBuilder is UTF16, it still has to check for all-Latin1 characters at the time of string creation, so not really an overhead elimination.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2049929906

From liach at openjdk.org  Fri Apr 18 02:52:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Apr 2025 02:52:40 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v5]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
 
 
Message-ID: 

On Fri, 18 Apr 2025 02:45:56 GMT, Chen Liang  wrote:

>> We need to provide a StringBuilder that creates a coder of UTF16 to avoid the unnecessary UTF16 to LATIN1 conversion overhead here. 
>> 
>> If we do not want to add a new public method, we can add an internal method and expose it through JLA for use here.
>
> `Reader` by specification works on `char`, so I think this is fine. Even if a StringBuilder is UTF16, it still has to check for all-Latin1 characters at the time of string creation, so not really an overhead elimination.

Seems you want to make the `result` StringBuilder fully expanded (maybeLatin1 = true, coder = UTF16) initially, so we just compress the whole builder with a vectorized intrinsic instead of char-by-char loop in `append`. Makes sense.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2049932051

From swen at openjdk.org  Fri Apr 18 02:55:42 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 18 Apr 2025 02:55:42 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v5]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
Message-ID: 

On Thu, 17 Apr 2025 23:07:35 GMT, Brian Burkhalter  wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8354724: Increment copyright year in Reader
>  - 8354724: Move readString from BufferedReader to Reader

src/java.base/share/classes/java/io/Reader.java line 420:

> 418:      */
> 419:     public String readString() throws IOException {
> 420:         StringBuilder result = new StringBuilder();

StringBuilder result = new StringBuilder().append('\u4e2d').delete(0, 1);

Of course, we can also create a StringBuilder with coder as UTF16 in this way, but such code smells bad.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2049934073

From duke at openjdk.org  Fri Apr 18 03:16:48 2025
From: duke at openjdk.org (He-Pin (kerr))
Date: Fri, 18 Apr 2025 03:16:48 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 28 Mar 2025 13:19:50 GMT, Viktor Klang  wrote:

>> He-Pin(kerr) has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - .
>>  - .
>
> test/jdk/java/util/concurrent/tck/ThreadPoolExecutorTest.java line 44:
> 
>> 42: import java.util.Collections;
>> 43: import java.util.List;
>> 44: import java.util.concurrent.ArrayBlockingQueue;
> 
> Hi @He-Pin,
> 
> I needed to perform the following changes to get this test to compile, and run successfully:
> 
> 
> diff --git a/test/jdk/java/util/concurrent/tck/ThreadPoolExecutorTest.java b/test/jdk/java/util/concurrent/tck/ThreadPoolExecutorTest.java
> index f23c421f97e..d9ce643a26d 100644
> --- a/test/jdk/java/util/concurrent/tck/ThreadPoolExecutorTest.java
> +++ b/test/jdk/java/util/concurrent/tck/ThreadPoolExecutorTest.java
> @@ -291,7 +291,7 @@ public void testSetThreadFactoryNull() {
>                  p.setThreadFactory(null);
>                  shouldThrow();
>              } catch (NullPointerException success) {
> -                Assert.assertEquals("threadFactory", success.getMessage());
> +                assertEquals("threadFactory", success.getMessage());
>              }
>          }
>      }
> @@ -353,7 +353,7 @@ public void testSetRejectedExecutionHandlerNull() {
>                  p.setRejectedExecutionHandler(null);
>                  shouldThrow();
>              } catch (NullPointerException success) {
> -                Assert.assertEquals("handler", success.getMessage());
> +                assertEquals("handler", success.getMessage());
>              }
>          }
>      }
> @@ -728,7 +728,7 @@ public void testConstructor1() {
>                                     new ArrayBlockingQueue(10));
>              shouldThrow();
>          } catch (IllegalArgumentException success) {
> -            Assert.assertEquals("corePoolSize must be non-negative");
> +            assertEquals("corePoolSize must be non-negative", success.getMessage());
>          }
>      }
>  
> @@ -741,7 +741,7 @@ public void testConstructor2() {
>                                     new ArrayBlockingQueue(10));
>              shouldThrow();
>          } catch (IllegalArgumentException success) {
> -            Assert.assertEquals("maximumPoolSize must be positive");
> +            assertEquals("maximumPoolSize must be positive", success.getMessage());
>          }
>      }
>  
> @@ -754,7 +754,7 @@ public void testConstructor3() {
>                                     new ArrayBlockingQueue(10));
>              shouldThrow();
>          } catch (IllegalArgumentException success) {
> -            Assert.assertEquals("maximumPoolSize must be positive", success.getMessage());
> +            assertEquals("maximumPoolSize must be positive", s...

Thank you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23050#discussion_r2049945473

From duke at openjdk.org  Fri Apr 18 03:22:28 2025
From: duke at openjdk.org (He-Pin (kerr))
Date: Fri, 18 Apr 2025 03:22:28 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message [v4]
In-Reply-To: 
References: 
Message-ID: 

> Motivation:
> When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful.
> 
> Modification:
> Add detail error messages.
> 
> Result:
> Helpful messages.

He-Pin(kerr) has updated the pull request incrementally with one additional commit since the last revision:

  chore: fix test error with the help of klang

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23050/files
  - new: https://git.openjdk.org/jdk/pull/23050/files/1e098b28..b4a10d1c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23050&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23050&range=02-03

  Stats: 57 lines in 1 file changed: 2 ins; 0 del; 55 mod
  Patch: https://git.openjdk.org/jdk/pull/23050.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23050/head:pull/23050

PR: https://git.openjdk.org/jdk/pull/23050

From liach at openjdk.org  Fri Apr 18 03:39:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Apr 2025 03:39:44 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
In-Reply-To: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
Message-ID: <_8oIoaRrodstOsLcs6BGkHH5zdTEkxeJvoIRRouJ0fM=.42bf4092-196c-40e1-935d-cf6c12b04b85@github.com>

On Thu, 17 Apr 2025 19:44:07 GMT, Chen Liang  wrote:

> Perf numbers for simple main:
> Linking of `Class::forName0` down from ~152 to ~83
> 
> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
> JNI: ~45
> baseline panama: ~164
> patch: ~103
> 
> Also see #24705.

Testing: tier 1-3

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24742#issuecomment-2814458553

From abakhtin at openjdk.org  Fri Apr 18 04:14:22 2025
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Fri, 18 Apr 2025 04:14:22 GMT
Subject: RFR: 8259540: MissingResourceException for key
 cvc-complex-type.2.4.d.1
Message-ID: 

Please find a trivial fix for the missing `cvc-complex-type.2.4.d.1` resource in the main XMLSchemaMessages.properties file.

-------------

Commit messages:
 - 8259540: MissingResourceException for key cvc-complex-type.2.4.d.1

Changes: https://git.openjdk.org/jdk/pull/24747/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24747&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8259540
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24747.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24747/head:pull/24747

PR: https://git.openjdk.org/jdk/pull/24747

From joehw at openjdk.org  Fri Apr 18 04:37:40 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 18 Apr 2025 04:37:40 GMT
Subject: RFR: 8259540: MissingResourceException for key
 cvc-complex-type.2.4.d.1
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Apr 2025 04:08:56 GMT, Alexey Bakhtin  wrote:

> Please find a trivial fix for the missing `cvc-complex-type.2.4.d.1` resource in the main XMLSchemaMessages.properties file.

LGTM. Added a link to JDK-8355006.

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24747#pullrequestreview-2777521247

From alanb at openjdk.org  Fri Apr 18 06:06:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 18 Apr 2025 06:06:52 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Apr 2025 21:29:21 GMT, Markus KARG  wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars()

test/jdk/java/nio/CharBuffer/GetChars.java line 34:

> 32:  * @run testng GetChars
> 33:  */
> 34: public class GetChars {

The tests for buffers, including CharBuffer, are in test/jdk/java/nio/Buffer. Look at the existing Chars.java tests idea, and specifically the DataProvider "createCharBuffers" as it will show the different kinds of CharBuffers that can be tested.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2050100315

From eirbjo at openjdk.org  Fri Apr 18 06:38:47 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 18 Apr 2025 06:38:47 GMT
Subject: RFR: 8354273: Restore even more pointless unicode characters to
 ASCII [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 10:36:31 GMT, Magnus Ihse Bursie  wrote:

>> As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213), I found some additional places where unicode characters are unnecessarily used instead of pure ASCII.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove incorrectly copied "?anchor"

While the changes here look okay, I think the issue/PR title could be improved.

The replacement of Unicode "En Dash" with ASCII hypen-minus and the similar relacement of the Unicode "Horizontal Ellipsis" with three ASCII periods are not really "restoring" much, and these unicode characters are hardly "pointless" as they may carry different semantic meaning, behavior and rendering. 

It's a valid chioce to normalize them into ASCII though, but perhaps a title like "Normalize even more Unicode characters as ASCII" would be more "fair" to these poor Unicode characters :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24567#issuecomment-2814667275

From swen at openjdk.org  Fri Apr 18 07:01:45 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 18 Apr 2025 07:01:45 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v5]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
 
 
 
Message-ID: <-Xv5K_oAaVhe3ppb3GV_Vo_cc5r7G4aWjbi-k09FwIk=.91ff9d1e-f8e2-4422-b203-4d0cb13c24cf@github.com>

On Fri, 18 Apr 2025 02:49:43 GMT, Chen Liang  wrote:

>> `Reader` by specification works on `char`, so I think this is fine. Even if a StringBuilder is UTF16, it still has to check for all-Latin1 characters at the time of string creation, so not really an overhead elimination.
>
> Seems you want to make the `result` StringBuilder fully expanded (maybeLatin1 = true, coder = UTF16) initially, so we just compress the whole builder with a vectorized intrinsic instead of char-by-char loop in `append`. Makes sense.

public static String readString() throws IOException {
        char[] chars = new char[TRANSFER_BUFFER_SIZE];
        int n;
        int off = 0;
        int rest = chars.length;
        while ((n = read(chars, off, rest)) != -1) {
            off += n;
            if (n == rest) {
                chars = Arrays.copyOf(chars, chars.length * 2);
            }
            rest = chars.length - off;
        }
        return new String(chars, 0, off);
    }

Maybe this version is better, it directly expands the capacity on char[] without using StringBuilder, has good performance, and does not need to add new methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2050182416

From alanb at openjdk.org  Fri Apr 18 08:13:41 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 18 Apr 2025 08:13:41 GMT
Subject: RFR: 8354450: Using a File with a path containing a trailing space
 should fail when alternative data streams are disabled (win) [v2]
In-Reply-To: 
References: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
 
 <1EKMYPzdR0EfG8v9_hauG3wPMw0_cRATLZlg0LbE4ps=.049a55bc-797a-4eb4-9b4a-f20b02cafbe4@github.com>
 
 <7LDV_FtSki03-PTPsSoobe3N-SbtcjVKzf933HBuFoQ=.474914b7-beda-4f80-8655-c0523bd23a87@github.com>
 
Message-ID: 

On Fri, 18 Apr 2025 01:01:50 GMT, Brian Burkhalter  wrote:

> From experimentation with C++ code is VS, it appears that `CreateDirectoryW` will create a directory with either a leading or trailing space in its name, whereas `createFileW` will create a file with a leading space in its name, but a trailing space is trimmed.

Right, the Windows APIs are very inconsistent on this, and why the Windows implementation of Path will always reject input where an element has a trailing space.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24635#discussion_r2050315986

From tschatzl at openjdk.org  Fri Apr 18 09:33:48 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 18 Apr 2025 09:33:48 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v34]
In-Reply-To: 
References: 
Message-ID: <3VD8WHNeCOwh3vgziKpuOctwd7CsOXM6uEVc1P6HSrg=.961011ff-9e7b-456d-bb70-f6ef89cc6735@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 two additional commits since the last revision:

 - * ayang review (part 2 - yield duration changes)
 - * ayang review (part 1)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/068d2a37..a3b2386d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=32-33

  Stats: 41 lines in 11 files changed: 1 ins; 11 del; 29 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  Fri Apr 18 10:08:52 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 18 Apr 2025 10:08:52 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v34]
In-Reply-To: <3VD8WHNeCOwh3vgziKpuOctwd7CsOXM6uEVc1P6HSrg=.961011ff-9e7b-456d-bb70-f6ef89cc6735@github.com>
References: 
 <3VD8WHNeCOwh3vgziKpuOctwd7CsOXM6uEVc1P6HSrg=.961011ff-9e7b-456d-bb70-f6ef89cc6735@github.com>
Message-ID: 

On Fri, 18 Apr 2025 09:33:48 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 two additional commits since the last revision:
> 
>  - * ayang review (part 2 - yield duration changes)
>  - * ayang review (part 1)

The current use of all filters in the barrier is intentional: there is additional work going on investigating that, and I did not want to anticipate it in this change.

When implementing the current `gen_write_ref_array_post` code measurements showed that the current version is slightly better than your suggestion for most arrays (everything larger than a few elements). I may still decide to use your version for now and re-measure later.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2815125500

From duke at openjdk.org  Fri Apr 18 11:36:14 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 18 Apr 2025 11:36:14 GMT
Subject: RFR: 8077587: BigInteger Roots [v10]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Memory usage optimization

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/5d971fac..e459c231

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From asemenyuk at openjdk.org  Fri Apr 18 12:15:53 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 18 Apr 2025 12:15:53 GMT
Subject: Integrated: 8354988: Separate stderr and stdout in Executor class from
 jpackage test lib
In-Reply-To: 
References: 
Message-ID: 

On Thu, 17 Apr 2025 23:47:09 GMT, Alexey Semenyuk  wrote:

> Rework Executor class from jpackage test lib to support separate configuration of stdout and stderr streams handling:
>  - New `Executor.discardStdout(boolean)` and `Executor.discardStderr(boolean)` methods enable/disable stdout and stderr streams, respectively;
>  - New `Executor.Result.stdout()` accesses saved stdout stream;
>  - New `Executor.Result.stderr()` accesses saved stderr stream;
>  - `Executor.Result.getOutput()` returns merged stdout and stderr streams. Contents of the stdout go first, contents of the stderr follow;
>  - New `JPackageCommand.discardStdout(boolean)` and `JPackageCommand.discardStderr(boolean)` methods enable/disable stdout and stderr streams produced by jpackage, respectively.
> 
> Additionally:
>  - Streamline `BasicTest.testErrorsAlwaysPrinted()`;
>  - Fix WindowsHelper and Win8301247Test as they stopped working as expected due to reordering the contents of stdout and stderr streams in the merged stream returned by `Executor.Result.getOutput()`.

This pull request has now been integrated.

Changeset: 22e8a97a
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/22e8a97a1ce4e1c781fbc6f1e271c477fe95f069
Stats:     659 lines in 7 files changed: 488 ins; 58 del; 113 mod

8354988: Separate stderr and stdout in Executor class from jpackage test lib

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/24745

From duke at openjdk.org  Fri Apr 18 12:34:42 2025
From: duke at openjdk.org (Markus KARG)
Date: Fri, 18 Apr 2025 12:34:42 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v7]
In-Reply-To: 
References: 
Message-ID: 

> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
> 
> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
> 
> To ensure quality...
> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  Applied changes requestes by Alan: Aligning unit test for CharBuffer.getChars() with unit test for CharBuffer.chars()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21730/files
  - new: https://git.openjdk.org/jdk/pull/21730/files/884e7dc1..cb2a2efb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21730&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21730&range=05-06

  Stats: 301 lines in 2 files changed: 207 ins; 94 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21730/head:pull/21730

PR: https://git.openjdk.org/jdk/pull/21730

From duke at openjdk.org  Fri Apr 18 12:37:49 2025
From: duke at openjdk.org (Markus KARG)
Date: Fri, 18 Apr 2025 12:37:49 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 18 Apr 2025 06:03:36 GMT, Alan Bateman  wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars()
>
> test/jdk/java/nio/CharBuffer/GetChars.java line 34:
> 
>> 32:  * @run testng GetChars
>> 33:  */
>> 34: public class GetChars {
> 
> The tests for buffers, including CharBuffer, are in test/jdk/java/nio/Buffer. Look at the existing Chars.java tests idea, and specifically the DataProvider "createCharBuffers" as it will show the different kinds of CharBuffers that can be tested.

Thank you for this tip, Alan! I have move the unit test from `nio/CharBuffer` to `nio/Buffer`, and appended it with the randomized test found in `Buffer/Chars.java`. Hope it looks fine now?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2050562477

From duke at openjdk.org  Fri Apr 18 12:37:48 2025
From: duke at openjdk.org (Markus KARG)
Date: Fri, 18 Apr 2025 12:37:48 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: 
References: 
 
 
 <6dAYgfNcUgA3z3iid8wXPNo3qhdhZGDbCgOfbfA0skE=.8194c6ee-81df-4170-a983-0283c2234d0b@github.com>
 
 <5VoTSyeoyECVkqefMEk2IRs1y64sXHLvkjM_vRBVUKM=.c8a9d588-d203-4962-9cfd-be867d5d3807@github.com>
 
Message-ID: 

On Wed, 16 Apr 2025 15:00:20 GMT, Roger Riggs  wrote:

>> Yeah, we already added this API to allow implementations to be more consistent under race condition. So for changing char sequences, this method's default implementation can throw IOOBE, but it is already specified so it is well-behaved even under race (as you can argue a read observed the shorter state of the CS that causes the failure)
>
> Omitting it is fine, it was just a reminder that an interface cannot make any definitive statements about its implementations and sometime should warn the unwary user. (We all expect them to adhere to the contract described in each method, but who knows.)
> The statement in the implSpec is fine as it only applies to the default implementation, but can be mis-read and thought to apply to all implementations. YMMV.
> And though I see consensus, I don't see any approvals yet, including the CSR.
> Its good to see it settle down and make progress.

Alan, I am a bit lost here. How to proceed: Change the JavaDocs, or keep them as found in the CSR?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2050565025

From dfuchs at openjdk.org  Fri Apr 18 13:29:17 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 18 Apr 2025 13:29:17 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
Message-ID: 

Hi,

Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).

The CSR can be viewed at [JDK-8350588: Implement 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.

-------------

Commit messages:
 - http3: jcheck - remove trailing white spaces
 - http3: jcheck - fixed bad file permission
 - merge latest changes from master branch
 - http3: increase keepalive timeout in H3MultipleConnectionsToSameHost.java
 - http3: improve logging on reception of stateless reset
 - http3: CSR feedback: renamed H3DiscoveryMode and associated constants
 - http3: comment update in Http3PushManager.java
 - http3: more consistent connection labels; the label now includes the underlying transport-level protocol: tcp:1, tls:2, quic:1
 - Add HTTP/3 cases to `HttpResponseConnectionLabelTest`
 - http3: adapt connection label to HttpQuicConnection after merge
 - ... and 388 more: https://git.openjdk.org/jdk/compare/4eae9b5b...9c2da664

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349910
  Stats: 102691 lines in 469 files changed: 100070 ins; 1119 del; 1502 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 swen at openjdk.org  Fri Apr 18 13:45:46 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 18 Apr 2025 13:45:46 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v5]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
Message-ID: <7oGHwT_9fVSVXUy3Z1O43xAxacXKbJ2WBum-Gy0rHdM=.dd37f0eb-c93f-4f21-a87e-d7ca73e7c263@github.com>

On Thu, 17 Apr 2025 23:07:35 GMT, Brian Burkhalter  wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8354724: Increment copyright year in Reader
>  - 8354724: Move readString from BufferedReader to Reader

https://github.com/bplb/jdk/pull/3
@bplb  I submitted a PR to you to optimize the readString implementation of InputStreamReader

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2815475700

From alanb at openjdk.org  Fri Apr 18 14:48:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 18 Apr 2025 14:48:49 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v5]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
Message-ID: 

On Thu, 17 Apr 2025 23:07:35 GMT, Brian Burkhalter  wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8354724: Increment copyright year in Reader
>  - 8354724: Move readString from BufferedReader to Reader

transferTo reads to EOS, readString and readAllLines reads to EOS too. As Reader is specified to not support a mark in the base class then I don't think it would be too bad to have Reader define a method to read the remaining characters as a sequence of lines. BufferedReader would then adding buffer, and methods that rely on buffering.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2815582041

From duke at openjdk.org  Fri Apr 18 15:05:49 2025
From: duke at openjdk.org (Glavo)
Date: Fri, 18 Apr 2025 15:05:49 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v5]
In-Reply-To: <-Xv5K_oAaVhe3ppb3GV_Vo_cc5r7G4aWjbi-k09FwIk=.91ff9d1e-f8e2-4422-b203-4d0cb13c24cf@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
 
 
 
 <-Xv5K_oAaVhe3ppb3GV_Vo_cc5r7G4aWjbi-k09FwIk=.91ff9d1e-f8e2-4422-b203-4d0cb13c24cf@github.com>
Message-ID: 

On Fri, 18 Apr 2025 06:59:18 GMT, Shaojin Wen  wrote:

>> Seems you want to make the `result` StringBuilder fully expanded (maybeLatin1 = true, coder = UTF16) initially, so we just compress the whole builder with a vectorized intrinsic instead of char-by-char loop in `append`. Makes sense.
>
> public static String readString() throws IOException {
>         char[] chars = new char[TRANSFER_BUFFER_SIZE];
>         int n;
>         int off = 0;
>         int rest = chars.length;
>         while ((n = read(chars, off, rest)) != -1) {
>             off += n;
>             if (n == rest) {
>                 chars = Arrays.copyOf(chars, chars.length * 2);
>             }
>             rest = chars.length - off;
>         }
>         return new String(chars, 0, off);
>     }
> 
> Maybe this version is better, it directly expands the capacity on char[] without using StringBuilder, has good performance, and does not need to add new methods.

Maybe it can be implemented by referring to `InputStream::readNBytes(int)` (The default implementation of `InputStream::readAllBytes()` is based on it):

https://github.com/openjdk/jdk/blob/22e8a97a1ce4e1c781fbc6f1e271c477fe95f069/src/java.base/share/classes/java/io/InputStream.java#L396-L458

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2050746983

From liach at openjdk.org  Fri Apr 18 15:12:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Apr 2025 15:12:52 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v5]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
 
 
 
 <-Xv5K_oAaVhe3ppb3GV_Vo_cc5r7G4aWjbi-k09FwIk=.91ff9d1e-f8e2-4422-b203-4d0cb13c24cf@github.com>
 
Message-ID: 

On Fri, 18 Apr 2025 15:02:56 GMT, Glavo  wrote:

>> public static String readString() throws IOException {
>>         char[] chars = new char[TRANSFER_BUFFER_SIZE];
>>         int n;
>>         int off = 0;
>>         int rest = chars.length;
>>         while ((n = read(chars, off, rest)) != -1) {
>>             off += n;
>>             if (n == rest) {
>>                 chars = Arrays.copyOf(chars, chars.length * 2);
>>             }
>>             rest = chars.length - off;
>>         }
>>         return new String(chars, 0, off);
>>     }
>> 
>> Maybe this version is better, it directly expands the capacity on char[] without using StringBuilder, has good performance, and does not need to add new methods.
>
> Maybe it can be implemented by referring to `InputStream::readNBytes(int)` (The default implementation of `InputStream::readAllBytes()` is based on it):
> 
> https://github.com/openjdk/jdk/blob/22e8a97a1ce4e1c781fbc6f1e271c477fe95f069/src/java.base/share/classes/java/io/InputStream.java#L396-L458

If accumulation of array is necessary, I think the "variable sized array" in #24232 may help/

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2050753970

From jvernee at openjdk.org  Fri Apr 18 15:20:16 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 18 Apr 2025 15:20:16 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v56]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 14:19:25 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments on original vs underlying

Did an initial pass over just the implementation. Will look at the tests later.

src/java.base/share/classes/java/lang/StableValue.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, 2025, Oracle and/or its affiliates. All rights reserved.

As far as I know, when the files are integrated into the mainline JDK, the copyright year should be set to the current year. For the FFM API we also had to reset all the years, even though the files had existed for a few years in the panama-foreign repo.

src/java.base/share/classes/java/lang/StableValue.java line 118:

> 116:  * The {@code getLogger()} method calls {@code logger.orElseSet()} on the stable value to
> 117:  * retrieve its content. If the stable value is unset, then {@code orElseSet()}
> 118:  * evaluates and sets the content; the content is then returned to the client. In other

What does 'orElseSet' evaluate? Feels like there's a bit missing in this sentence. Maybe:

Suggestion:

 * retrieve its content. If the stable value is unset, then {@code orElseSet()}
 * evaluates the given supplier, and sets the content to the result; the content is then returned to the client. In other

src/java.base/share/classes/java/lang/StableValue.java line 126:

> 124:  * This property is crucial as evaluation of the supplier may have side effects,
> 125:  * e.g., the call above to {@code Logger.create()} may result in storage resources
> 126:  * being prepared.

I think it's better to avoid abbreviations like 'e.g.' in javadoc, and go for the full 'for example'.

Also, WRT the contents of this paragraph: if multiple threads execute the `orElseSet` statement concurrently, multiple different `Supplier` instances might be created and passed to `orElseSet`. I think the method guarantees that only one of these (multiple) suppliers will be evaluated. But, technically, there is no 'the supplier', I suppose.

src/java.base/share/classes/java/lang/StableValue.java line 282:

> 280:  * A stable value can depend on other stable values, forming a dependency graph
> 281:  * that can be lazily computed but where access to individual elements still can be
> 282:  * performant. In the following example, a single {@code Foo} and a {@code Bar}

Word order doesn't seem right here.

Suggestion:

 * that can be lazily computed but where access to individual elements can still be
 * performant. In the following example, a single {@code Foo} and a {@code Bar}

src/java.base/share/classes/java/lang/StableValue.java line 344:

> 342:  * 

> 343:  * The fibonacci example above is a dependency graph with no circular dependencies (i.e.,
> 344:  * it is a dependency tree):

I believe the technical term here is 'directed acyclic graph'

src/java.base/share/classes/java/lang/StableValue.java line 363:

> 361:  * The content of a stable value is guaranteed to be set at most once. If competing
> 362:  * threads are racing to set a stable value, only one update succeeds, while other updates
> 363:  * are blocked until the stable value becomes set.

I think it would be good to say here that the blocked updates will be discarded, or something to that effect. The current sentence can be interpreted as the blocked updates still taking place after the SV becomes set.

src/java.base/share/classes/java/lang/StableValue.java line 385:

> 383:  * The method {@link #orElseSet(Supplier)} guarantees that the provided
> 384:  * {@linkplain Supplier} is invoked successfully at most once even under race.
> 385:  * Invocations of {@link #setOrThrow(Object)} forms a total order of zero or more

Suggestion:

 * Invocations of {@link #setOrThrow(Object)} form a total order of zero or more

src/java.base/share/classes/java/lang/StableValue.java line 389:

> 387:  * successful invocation. Since stable functions and stable collections are built on top
> 388:  * of {@linkplain StableValue#orElseSet(Supplier) orElseSet()} they too are
> 389:  * thread safe and guarantee at-most-once-per-input invocation.

I think you should drop the note here about stable collections being built on top of `orElseSet`. This is an interesting implementation detail, but not directly relevant for the specification, and some that we might want to change in the future.

I suggest just specifying the behavior of stable collections directly, without mentioning how they are implemented.

src/java.base/share/classes/java/lang/StableValue.java line 396:

> 394:  * stable value itself is stored in a {@code static final} field). Stable functions and
> 395:  * collections are built on top of StableValue. As such, they are also treated as
> 396:  * constants by the JVM.

This doesn't seem quite correct. stable collections aren't necessarily treated as constant, you need a constant reference, e.g. stored in a static final field. The contents can be treated as constant though.

Suggestion:

 * collections are built on top of StableValue. As such, their contents is also treated as
 * constant by the JVM.

src/java.base/share/classes/java/lang/StableValue.java line 400:

> 398:  * This means that, at least in some cases, access to the content of a stable value
> 399:  * enjoys the same constant-folding optimizations that are available when accessing
> 400:  * {@code static final} fields.

This text seems too normative to me. Whether a JVM implementation chooses to constant fold things is up to that JVM implementation, and not something that is required of _all_ JVM implementations.

I think you could say something like: "since the contents of a stable value can never change after it has been set, a JVM implementation may, for a set stable value, elide all future reads of that stable value, and instead directly use any contents that it has previously observed"

src/java.base/share/classes/java/lang/StableValue.java line 405:

> 403:  *           {@code this} and consequently, care should be taken whenever
> 404:  *           (directly or indirectly) synchronizing on a {@code StableValue}. Failure to
> 405:  *           do this may lead to deadlock. Stable functions and collections on the

Given the previous sentence, in this sentence, 'this' could interpreted as 'synchronizing on a stable value' (and failing to do so may lead to dealock). You might want to reword this a bit.

src/java.base/share/classes/java/lang/StableValue.java line 432:

> 430:  *           stable values of arbitrary depth and still provide transitive constantness.
> 431:  *           Stable values, functions and collections are not {@link Serializable}.
> 432:  *

This last sentence should probably be a separate implSpec

src/java.base/share/classes/java/lang/StableValue.java line 454:

> 452:      * @param content to set
> 453:      * @throws IllegalStateException if this method is invoked directly by a supplier
> 454:      *         provided to the {@link #orElseSet(Supplier)} method.

Why does this result in an exception? Given the example of dependent SV's I thought it would be fine or e.g. a stable value A to initialize another stable value B using `trySet`.

src/java.base/share/classes/java/lang/StableValue.java line 569:

> 567:      * returned supplier's {@linkplain Supplier#get() get()} method when a value is
> 568:      * already under computation will block until a value is computed or an exception is
> 569:      * thrown by the computing thread.

Similar here, I think you could add a note saying that blocked threads will not evaluate their supplier after resuming if the SV has already been set.

src/java.base/share/classes/java/lang/StableValue.java line 592:

> 590:      * function upon being first accessed via the returned function's
> 591:      * {@linkplain IntFunction#apply(int) apply()} method. If the returned function is
> 592:      * invoked with an input that is not allowed, an {@link IllegalArgumentException}

Same here:

Suggestion:

     * invoked with an input that is not in the range {@code [0, size)}, an {@link IllegalArgumentException}

src/java.base/share/classes/java/lang/StableValue.java line 606:

> 604:      * 

> 605:      * If the provided {@code underlying} function recursively calls the returned
> 606:      * function for the same index, an {@linkplain IllegalStateException} will

This is the only place where I see the word 'index' used. Elsewhere you use 'input'. Might want to switch to the latter here as well.

Suggestion:

     * function for the same input, an {@linkplain IllegalStateException} will

src/java.base/share/classes/java/lang/StableValue.java line 609:

> 607:      * be thrown.
> 608:      *
> 609:      * @param size       the size of the allowed inputs in {@code [0, size)}

I think it's worth mentioning somewhere that the inputs to the int function are contiguous, starting at `0`.

src/java.base/share/classes/java/lang/StableValue.java line 617:

> 615:                                           IntFunction underlying) {
> 616:         if (size < 0) {
> 617:             throw new IllegalArgumentException();

Please add an exception message.

src/java.base/share/classes/java/lang/StableValue.java line 630:

> 628:      * {@code underlying} function upon being first accessed via the returned function's
> 629:      * {@linkplain Function#apply(Object) apply()} method. If the returned function is
> 630:      * invoked with an input that is not allowed, an {@link IllegalArgumentException}

I think 'not allowed' is too vague.

Suggestion:

     * invoked with an input that is not in {@code inputs}, an {@link IllegalArgumentException}

src/java.base/share/classes/java/lang/StableValue.java line 647:

> 645:      *
> 646:      * @param inputs     the set of (non-null) allowed input values
> 647:      * @param underlying Function used to compute cached values

Looks like some code tags are missing here and for `intFunction`?

Suggestion:

     * @param underlying {@code Function} used to compute cached values

src/java.base/share/classes/java/lang/StableValue.java line 651:

> 649:      * @param         the type of results delivered by the returned Function
> 650:      * @throws NullPointerException if the provided set of {@code inputs} contains a
> 651:      *                              {@code null} element.

This doesn't seem to be checked by this method.

src/java.base/share/classes/java/lang/StableValue.java line 700:

> 698:                             IntFunction mapper) {
> 699:         if (size < 0) {
> 700:             throw new IllegalArgumentException();

Please add an exception message here too.

src/java.base/share/classes/java/lang/StableValue.java line 738:

> 736:      * @param     the type of mapped values in the returned map
> 737:      * @throws NullPointerException if the provided set of {@code inputs} contains a
> 738:      *                              {@code null} element.

Here also, this does not seem to be checked by this method.

src/java.base/share/classes/java/util/ImmutableCollections.java line 1592:

> 1590:                     final K k = inner.getKey();
> 1591:                     return new NullableKeyValueHolder<>(k, inner.getValue().orElseSet(new Supplier() {
> 1592:                         @Override public V get() { return mapper.apply(k); }}));

I suppose you could potentially make this more lazy by returning an `Entry` implementation that only evaluates the mapper when calling `Entry::getValue`.

src/java.base/share/classes/java/util/ImmutableCollections.java line 1630:

> 1628:                         @SuppressWarnings("unchecked")
> 1629:                         var array = (StableValueImpl[]) Array.newInstance(StableValueImpl.class, len);
> 1630:                         return array;

No need to use reflection here, since the array type is statically known.

Suggestion:

                        return new StableValueImpl[len];

src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 71:

> 69:         } catch (ArrayIndexOutOfBoundsException ioob) {
> 70:             throw new IllegalArgumentException("Input not allowed: " + value, ioob);
> 71:         }

This AIOOBE should not be possible, right? The `member` test already checks that the key is valid. Meaning that, if an AIOOBE is thrown here, there's a bug elsewhere.

src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 71:

> 69:         } catch (ArrayIndexOutOfBoundsException ioob) {
> 70:             throw new IllegalArgumentException("Input not allowed: " + value, ioob);
> 71:         }

Suggestion:

        final StableValueImpl delegate = delegates[index];

src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 111:

> 109:             min = Math.min(min, ordinal);
> 110:             max = Math.max(max, ordinal);
> 111:             bitSet.set(ordinal);

This doesn't look right wrt the way the bitset is initialized. `ordinal` can be larger than `inputs.size()`. For example for `enum X { A, B, C }` where the key set is `{ C }`.

src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 115:

> 113: 
> 114:         final int size = max - min + 1;
> 115:         final Class enumType = (Class)inputs.iterator().next().getClass();

Maybe you could make the type of `input` EnumSet, and then grab the element type directly.

src/java.base/share/classes/jdk/internal/lang/stable/StableUtil.java line 27:

> 25:         boolean first = true;
> 26:         for (int i = 0; i < length; i++) {
> 27:             if (first) { first = false; } else { sb.append(", "); }

This kind of behavior can be achieved using `StringJoiner` instead of `StringBuilder`.

src/java.base/share/classes/jdk/internal/lang/stable/StableUtil.java line 63:

> 61:     public static  StableValueImpl[] array(int size) {
> 62:         if (size < 0) {
> 63:             throw new IllegalArgumentException();

Please add an exception message

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 96:

> 94:     public void setOrThrow(T content) {
> 95:         if (!trySet(content)) {
> 96:             // Neither the set content nor the provided content is reveled in the

Suggestion:

            // Neither the set content nor the provided content is revealed in the

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 173:

> 171:     private void preventReentry() {
> 172:         if (Thread.holdsLock(this)) {
> 173:             throw new IllegalStateException("Recursive initialization is not supported");

Prevent users from having to look through the stack trace. Also, 'supported' sounds like it might be implemented later. I think 'allowed' is better to signal that this is an invariant.

Suggestion:

            throw new IllegalStateException("Recursive initialization of a StableValue is not allowed");

-------------

PR Review: https://git.openjdk.org/jdk/pull/23972#pullrequestreview-2776306916
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050719259
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2049279945
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2049293638
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050544213
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050547076
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050562079
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050578035
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050583697
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050589462
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050594539
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050604082
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050612306
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050617637
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050631923
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050647058
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050647863
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050637730
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050640199
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050643027
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050651143
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050652258
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050654014
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050691198
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050713377
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050716955
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050734308
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050735452
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050727569
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050732724
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050740555
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050743057
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050746822
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050751830

From jvernee at openjdk.org  Fri Apr 18 15:20:17 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 18 Apr 2025 15:20:17 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v56]
In-Reply-To: <5Fch16i4tli5STNrBlXneMqNpq5z6JhKuHNhBbf73Qg=.2c76fc01-e702-4615-b39a-64f16be89879@github.com>
References: 
 
 <5Fch16i4tli5STNrBlXneMqNpq5z6JhKuHNhBbf73Qg=.2c76fc01-e702-4615-b39a-64f16be89879@github.com>
Message-ID: 

On Thu, 17 Apr 2025 10:47:03 GMT, Viktor Klang  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address comments on original vs underlying
>
> src/java.base/share/classes/java/lang/StableValue.java line 422:
> 
>> 420:  *           As objects can be set via stable values but never removed, this can be a source
>> 421:  *           of unintended memory leaks. A stable value's content is
>> 422:  *           {@linkplain java.lang.ref##reachability strongly reachable}. Clients are
> 
> I wonder if "Clients" is the best word here. Perhaps "Developers"?

I think you can drop the 'clients are advised that' prefix here. (I think usually it's 'X are advised to Y', and you would use 'be advised that X' as a general statement.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050610207

From jvernee at openjdk.org  Fri Apr 18 15:20:16 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 18 Apr 2025 15:20:16 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33]
In-Reply-To: 
References: 
 
 
 <3arhaBIc5A-NbGpFZ_ehEMQhTzXSeIlel9cFNWwg9gE=.a1f457a0-ed07-4016-82ea-bace156ff4e9@github.com>
 
Message-ID: 

On Thu, 3 Apr 2025 09:47:15 GMT, Viktor Klang  wrote:

>> I think it should be "content" as only one element can be set?
>
> I'm definitely not an expert here, so I'll defer to someone more knowledgable :)

I asked around/looked this up, and it seems 'contents' would be more correct here, since a StableValue is primarily a container of things (you put things into it, get things out).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050694148

From jvernee at openjdk.org  Fri Apr 18 15:20:17 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 18 Apr 2025 15:20:17 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v56]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 18 Apr 2025 13:19:05 GMT, Jorn Vernee  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address comments on original vs underlying
>
> src/java.base/share/classes/java/lang/StableValue.java line 454:
> 
>> 452:      * @param content to set
>> 453:      * @throws IllegalStateException if this method is invoked directly by a supplier
>> 454:      *         provided to the {@link #orElseSet(Supplier)} method.
> 
> Why does this result in an exception? Given the example of dependent SV's I thought it would be fine or e.g. a stable value A to initialize another stable value B using `trySet`.

I see now the exception specification for `orElseSet`, I suggest saying something similar here:
Suggestion:

     * @throws IllegalStateException if a supplier invoked by {@link #orElseSet(Supplier)} recursively
     *         attempts to set this stable value by calling this method.

> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 173:
> 
>> 171:     private void preventReentry() {
>> 172:         if (Thread.holdsLock(this)) {
>> 173:             throw new IllegalStateException("Recursive initialization is not supported");
> 
> Prevent users from having to look through the stack trace. Also, 'supported' sounds like it might be implemented later. I think 'allowed' is better to signal that this is an invariant.
> 
> Suggestion:
> 
>             throw new IllegalStateException("Recursive initialization of a StableValue is not allowed");

Or maybe a message like "Illegal recursive initialization of stable value".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050625500
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050761523

From liach at openjdk.org  Fri Apr 18 15:34:09 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Apr 2025 15:34:09 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v56]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 18 Apr 2025 12:33:49 GMT, Jorn Vernee  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address comments on original vs underlying
>
> src/java.base/share/classes/java/lang/StableValue.java line 363:
> 
>> 361:  * The content of a stable value is guaranteed to be set at most once. If competing
>> 362:  * threads are racing to set a stable value, only one update succeeds, while other updates
>> 363:  * are blocked until the stable value becomes set.
> 
> I think it would be good to say here that the blocked updates will be discarded, or something to that effect. The current sentence can be interpreted as the blocked updates still taking place after the SV becomes set.

Indeed, something like "other updates will block and then observe the stable value is set"

> src/java.base/share/classes/java/lang/StableValue.java line 396:
> 
>> 394:  * stable value itself is stored in a {@code static final} field). Stable functions and
>> 395:  * collections are built on top of StableValue. As such, they are also treated as
>> 396:  * constants by the JVM.
> 
> This doesn't seem quite correct. stable collections aren't necessarily treated as constant, you need a constant reference, e.g. stored in a static final field. The contents can be treated as constant though.
> 
> Suggestion:
> 
>  * collections are built on top of StableValue. As such, their contents is also treated as
>  * constant by the JVM.

"their contents are"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050775415
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2050775808

From bpb at openjdk.org  Fri Apr 18 15:49:50 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 18 Apr 2025 15:49:50 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v5]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
Message-ID: 

On Fri, 18 Apr 2025 14:46:08 GMT, Alan Bateman  wrote:

> I don't think it would be too bad to have Reader define a method to read the remaining characters as a sequence of lines.

So you are suggesting moving `readAllLines` up from `BufferedReader` to `Reader`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2815678776

From bpb at openjdk.org  Fri Apr 18 15:55:47 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 18 Apr 2025 15:55:47 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v5]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
Message-ID: <8PLvAGjOo8HVZmfGq0mSIa1SpN5hevPsM5QapUp_tfU=.ff47df02-9473-44fb-a41f-f3242a28cedc@github.com>

On Thu, 17 Apr 2025 23:07:35 GMT, Brian Burkhalter  wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8354724: Increment copyright year in Reader
>  - 8354724: Move readString from BufferedReader to Reader

As a general comment, I don't think that optimization should be a focal point in this request. I think the purpose here is to make sure that the methods are in the right place, the specification is correct, and the implementation is correct, if not optimal. Performance tuning can be dealt with in (a) subsequent issue(s).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2815687444

From alanb at openjdk.org  Fri Apr 18 16:01:41 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 18 Apr 2025 16:01:41 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v5]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
 
Message-ID: 

On Fri, 18 Apr 2025 15:47:07 GMT, Brian Burkhalter  wrote:

> So you are suggesting moving `readAllLines` up from `BufferedReader` to `Reader`?

I think add it to the list to explore as a non-buffered Reader could support it, esp. when it doesn't support a mark. There are advantages and disadvantages of course and I think you'll need to write these down to help decide what APIs might make sense to expose, and where.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2815696416

From liach at openjdk.org  Fri Apr 18 16:13:42 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Apr 2025 16:13:42 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> Some AccessFlag parsing methods throw IAE because a flag mask is not valid in a location. However, there is no easy way to check what flag mask bits or what flags are valid for a location. We need such APIs to check, specific to each class file format version.
> 
> Also in the investigation, it's noted that `ACC_SYNTHETIC` is incorrectly represented - it is available since release 5.0 instead of release 7. This bug is fixed together for implementation simplicity.
> 
> The new methods are all in `AccessFlag.Location`:
> - `Set flags()`
> - `int flagsMask()`
> - `Set flags(ClassFileFormatVersion)`
> - `int flagsMask(ClassFileFormatVersion)`
> 
> Also there is some simplification to `AccessFlag` itself to remove the anonymous classes, which should be more startup-friendly.
> 
> Testing: Tier 1-3

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-location-accessors
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-location-accessors
 - More links
 - ClassLoading order, Typos in NPE test
 - 8347471: Provide valid flags and mask in AccessFlag.Location

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23095/files
  - new: https://git.openjdk.org/jdk/pull/23095/files/27faa8b2..5b862990

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23095&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23095&range=01-02

  Stats: 439534 lines in 5544 files changed: 135834 ins; 272684 del; 31016 mod
  Patch: https://git.openjdk.org/jdk/pull/23095.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23095/head:pull/23095

PR: https://git.openjdk.org/jdk/pull/23095

From jvernee at openjdk.org  Fri Apr 18 17:09:51 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 18 Apr 2025 17:09:51 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Apr 2025 18:03:47 GMT, Vladimir Ivanov  wrote:

>> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
>> 
>> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
>> 
>> The patch consists of the following parts:
>>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
>> 
>> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
>> 
>> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
>> 
>> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
>> 
>> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
>> 
>> Thanks!
>
> Vladimir Ivanov 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 24 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into vector.math.01.java
>  - RVV and SVE adjustments
>  - fix broken merge
>  - Merge branch 'master' into vector.math.01.java
>  - Fix debugName handling
>  - Merge branch 'master' into vector.math.01.java
>  - RVV and SVE adjustments
>  - Merge branch 'master' into vector.math.01.java
>  - Fix windows-aarch64 build failure
>  - features_string -> cpu_info_string
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/7b477dbf...88eacc48

Very interesting! Looks mostly good to me. Left a few inline notes.

src/hotspot/share/prims/vectorSupport.cpp line 622:

> 620: 
> 621:   ThreadToNativeFromVM ttn(thread);
> 622:   return env->NewStringUTF(features_string);

Isn't there a way to do this without the extra transition?

How about:


  oop result = java_lang_String::create_oop_from_str((char*) bytes, CHECK_NULL);
  return (jstring) JNIHandles::make_local(THREAD, result);

src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 379:

> 377:     V libraryBinaryOp(long addr, Class vClass, Class eClass, int length, String debugName,
> 378:                       V v1, V v2,
> 379:                       BinaryOperation defaultImpl) {

I notice that the bound of `V` differs between `libraryUnaryOp`, which uses `Vectory` and this method, which uses `VectorPayload`. Not sure if this is intentional?

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 272:

> 270:                 MemorySegment addr = LOOKUP.findOrThrow(symbol);
> 271:                 debug("%s %s => 0x%016x\n", op, symbol, addr.address());
> 272:                 T impl = implSupplier.apply(opc); // TODO: should call the very same native implementation eventually (once FFM API supports vectors)

FWIW, one current barrier I see to implementing the vector calling convention in the linker, is that the FFM linker (currently) transmits register values to the downcall stub use Java primitive types. So, in order to support vector calling conventions, we would need to add some kind of 'primitive' that can hold the entire vector value, and preferably gets passed in the right register.

However, I think in the case of these math libraries in particular, speed of the fallback implementation is not that much of an issue, since there is also an intrinsic. So alternatively, we could split a vector value up into smaller integral types (`int`, `long`) -> pass them to the downcall stub in that form -> and then reconstruct the full vector value in its target register. (I used the same trick when I was experimenting with FP80 support, which also requires splitting up the 80 bit value up into 2 `long`s).

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 305:

> 303:     @ForceInline
> 304:     /*package-private*/ static
> 305:     >

Here you're using `Vector` instead of `VectorPayload` for the binary op, so there seems to be a discrepancy with `VectorSupport`.

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24462#pullrequestreview-2778903954
PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2050830705
PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2050818654
PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2050875854
PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2050869087

From abakhtin at openjdk.org  Fri Apr 18 17:13:35 2025
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Fri, 18 Apr 2025 17:13:35 GMT
Subject: RFR: 8259540: MissingResourceException for key
 cvc-complex-type.2.4.d.1 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please find a trivial fix for the missing `cvc-complex-type.2.4.d.1` resource in the main XMLSchemaMessages.properties file.

Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:

  Add locolizations for _de, _ja and _zh_CN

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24747/files
  - new: https://git.openjdk.org/jdk/pull/24747/files/a49a14da..3ad1f7f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24747&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24747&range=00-01

  Stats: 3 lines in 3 files changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24747.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24747/head:pull/24747

PR: https://git.openjdk.org/jdk/pull/24747

From abakhtin at openjdk.org  Fri Apr 18 17:13:36 2025
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Fri, 18 Apr 2025 17:13:36 GMT
Subject: RFR: 8259540: MissingResourceException for key
 cvc-complex-type.2.4.d.1
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Apr 2025 04:08:56 GMT, Alexey Bakhtin  wrote:

> Please find a trivial fix for the missing `cvc-complex-type.2.4.d.1` resource in the main XMLSchemaMessages.properties file.

Added missed localized strings for _de, _ja and _zh_CN localities based on the JDK11 localizations

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24747#issuecomment-2815866680

From joehw at openjdk.org  Fri Apr 18 17:13:36 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 18 Apr 2025 17:13:36 GMT
Subject: RFR: 8259540: MissingResourceException for key
 cvc-complex-type.2.4.d.1
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Apr 2025 04:08:56 GMT, Alexey Bakhtin  wrote:

> Please find a trivial fix for the missing `cvc-complex-type.2.4.d.1` resource in the main XMLSchemaMessages.properties file.

@alexeybakhtin also, I assigned the issue to you. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24747#issuecomment-2815858373

From naoto at openjdk.org  Fri Apr 18 17:14:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 18 Apr 2025 17:14:52 GMT
Subject: RFR: 8354344: Test behavior after cut-over for future ISO 4217
 currency [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Apr 2025 23:06:04 GMT, Justin Lu  wrote:

>> Please review this PR which improves the _ValidateISO4217_ Currency test by adding testing of future currencies after the transition date.
>> 
>> This is done by creating a patched version of Currency that replaces `System.currentTimeMillis()` calls with a mocked value equivalent to `Long.MAX_VALUE`. A module patch is then applied to supply the new Currency class files.
>> 
>> The mocked time behavior is tested by using the `currency.properties` override in a separate invocation.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naoto review - check instruction owner. check module patch files exist

LGTM. Thanks for providing the test!

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24701#pullrequestreview-2779037686

From abarashev at openjdk.org  Fri Apr 18 17:31:54 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 18 Apr 2025 17:31:54 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX
Message-ID: 

The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check of the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust.

-------------

Commit messages:
 - Rework unit tests
 - Use standard PKIX alias
 - Merge branch 'master' into JDK-8272875
 - 8272875: Change the default key manager to PKIX

Changes: https://git.openjdk.org/jdk/pull/24756/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24756&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8272875
  Stats: 213 lines in 10 files changed: 158 ins; 25 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/24756.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24756/head:pull/24756

PR: https://git.openjdk.org/jdk/pull/24756

From smarks at openjdk.org  Fri Apr 18 17:37:45 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 18 Apr 2025 17:37:45 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v5]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
Message-ID: 

On Thu, 17 Apr 2025 23:07:35 GMT, Brian Burkhalter  wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8354724: Increment copyright year in Reader
>  - 8354724: Move readString from BufferedReader to Reader

A couple responses to previous comments:

Optimization. I concur with @bplb here; the discussion of encodings and trying to avoid reallocation/copying and such really feels like premature optimization. Let's make sure we get the API and specs right first.

Line-oriented methods on Reader instead of BufferedReader.

In a sense it would be nice if the line-oriented stuff, which bottoms out at readLine(), were on Reader instead of on BufferedReader. I did an investigation of this a while back and concluded that this isn't possible, at least not compatibly. The reason is the way lines are defined by BufferedReader. Specifically: a line is terminated by a CR, an LF, or a CRLF. There's logic in readLine() that terminates the current line if a CR is encountered, and it _also_ sets a `skipLF` flag which skips the LF if it's the very next character. This is an instance field of BufferedReader. The problem is that if this were promoted to Reader, this would change the behavior of existing methods.

Maybe somebody can come up with a clever way to avoid these behavior changes. Or, maybe we might decide this change is sufficiently compatible as to be acceptable. I thought about this for a while and concluded that we couldn't do this. But I could be convinced otherwise by sufficiently rigorous analysis.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2815902725

From liach at openjdk.org  Fri Apr 18 17:39:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Apr 2025 17:39:05 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v4]
In-Reply-To: 
References: 
Message-ID: <99C07UHobADrvIk56VyeU7dPnfyhvaurdo0EGVptUAo=.1385e695-6727-441d-bb31-dd3ec522f671@github.com>

> Some AccessFlag parsing methods throw IAE because a flag mask is not valid in a location. However, there is no easy way to check what flag mask bits or what flags are valid for a location. We need such APIs to check, specific to each class file format version.
> 
> Also in the investigation, it's noted that `ACC_SYNTHETIC` is incorrectly represented - it is available since release 5.0 instead of release 7. This bug is fixed together for implementation simplicity.
> 
> The new methods are all in `AccessFlag.Location`:
> - `Set flags()`
> - `int flagsMask()`
> - `Set flags(ClassFileFormatVersion)`
> - `int flagsMask(ClassFileFormatVersion)`
> 
> Also there is some simplification to `AccessFlag` itself to remove the anonymous classes, which should be more startup-friendly.
> 
> Testing: Tier 1-3

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Further enhance the impl of access flags, make cffv aware to flags easier

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23095/files
  - new: https://git.openjdk.org/jdk/pull/23095/files/5b862990..303edd90

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23095&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23095&range=02-03

  Stats: 152 lines in 1 file changed: 91 ins; 10 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/23095.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23095/head:pull/23095

PR: https://git.openjdk.org/jdk/pull/23095

From joehw at openjdk.org  Fri Apr 18 17:42:45 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 18 Apr 2025 17:42:45 GMT
Subject: RFR: 8259540: MissingResourceException for key
 cvc-complex-type.2.4.d.1
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 18 Apr 2025 17:09:40 GMT, Alexey Bakhtin  wrote:

> Added missed localized strings for _de, _ja and _zh_CN localities based on the JDK11 localizations

Probably not necessary as they will be covered by L10n resource update.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24747#issuecomment-2815909714

From jvernee at openjdk.org  Fri Apr 18 17:52:45 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 18 Apr 2025 17:52:45 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
In-Reply-To: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
Message-ID: 

On Thu, 17 Apr 2025 19:44:07 GMT, Chen Liang  wrote:

> Perf numbers for simple main:
> Linking of `Class::forName0` down from ~152 to ~83
> 
> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
> JNI: ~45
> baseline panama: ~164
> patch: ~103
> 
> Also see #24705.

make/jdk/src/classes/build/tools/classlist/HelloClasslist.java line 190:

> 188:                 JAVA_BOOLEAN, ADDRESS, ADDRESS);
> 189:         Optional symbol = lookup.find("Java_java_lang_Class_forName0");
> 190:         var _ = linker.downcallHandle(symbol.orElseThrow(), signature);

FWIW, passing just the signature should result in mostly the same code being generated. The address is just attached using MethodHandles::insertArguments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2050929830

From liach at openjdk.org  Fri Apr 18 17:59:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Apr 2025 17:59:59 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
In-Reply-To: 
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 
Message-ID: 

On Fri, 18 Apr 2025 17:49:35 GMT, Jorn Vernee  wrote:

>> Perf numbers for simple main:
>> Linking of `Class::forName0` down from ~152 to ~83
>> 
>> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
>> JNI: ~45
>> baseline panama: ~164
>> patch: ~103
>> 
>> Also see #24705.
>
> make/jdk/src/classes/build/tools/classlist/HelloClasslist.java line 190:
> 
>> 188:                 JAVA_BOOLEAN, ADDRESS, ADDRESS);
>> 189:         Optional symbol = lookup.find("Java_java_lang_Class_forName0");
>> 190:         var _ = linker.downcallHandle(symbol.orElseThrow(), signature);
> 
> FWIW, passing just the signature should result in mostly the same code being generated. The address is just attached using MethodHandles::insertArguments.

So just `Linker.nativeLinker().downcallHandle(MemorySegment.ofArray(new byte[0]), signature)` suffices?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2050937126

From jvernee at openjdk.org  Fri Apr 18 18:17:46 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 18 Apr 2025 18:17:46 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
In-Reply-To: 
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 
 
Message-ID: 

On Fri, 18 Apr 2025 17:56:53 GMT, Chen Liang  wrote:

>> make/jdk/src/classes/build/tools/classlist/HelloClasslist.java line 190:
>> 
>>> 188:                 JAVA_BOOLEAN, ADDRESS, ADDRESS);
>>> 189:         Optional symbol = lookup.find("Java_java_lang_Class_forName0");
>>> 190:         var _ = linker.downcallHandle(symbol.orElseThrow(), signature);
>> 
>> FWIW, passing just the signature should result in mostly the same code being generated. The address is just attached using MethodHandles::insertArguments.
>
> So just `Linker.nativeLinker().downcallHandle(MemorySegment.ofArray(new byte[0]), signature)` suffices?

Yes, that would work, but I was thinking just `Linker.nativeLinker().downcallHandle(signature)`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2050958874

From bpb at openjdk.org  Fri Apr 18 18:21:52 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 18 Apr 2025 18:21:52 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v5]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
Message-ID: 

On Fri, 18 Apr 2025 17:35:00 GMT, Stuart Marks  wrote:

> There's logic in readLine() that terminates the current line if a CR is encountered, and it _also_ sets a `skipLF` flag which skips the LF if it's the very next character.

I will also point out here that, based on a somewhat cursory search, it looks like every implementation of `readLine` has a "push back" capability. For example, `BufferedReader` has the character buffer `cb`, and both `RandomAccessFile` and `ImageInputStream[Impl]` use `seek` to backtrack.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2815968847

From liach at openjdk.org  Fri Apr 18 18:22:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Apr 2025 18:22:50 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v4]
In-Reply-To: <99C07UHobADrvIk56VyeU7dPnfyhvaurdo0EGVptUAo=.1385e695-6727-441d-bb31-dd3ec522f671@github.com>
References: 
 <99C07UHobADrvIk56VyeU7dPnfyhvaurdo0EGVptUAo=.1385e695-6727-441d-bb31-dd3ec522f671@github.com>
Message-ID: 

On Fri, 18 Apr 2025 17:39:05 GMT, Chen Liang  wrote:

>> Some AccessFlag parsing methods throw IAE because a flag mask is not valid in a location. However, there is no easy way to check what flag mask bits or what flags are valid for a location. We need such APIs to check, specific to each class file format version.
>> 
>> Also in the investigation, it's noted that `ACC_SYNTHETIC` is incorrectly represented - it is available since release 5.0 instead of release 7. This bug is fixed together for implementation simplicity.
>> 
>> The new methods are all in `AccessFlag.Location`:
>> - `Set flags()`
>> - `int flagsMask()`
>> - `Set flags(ClassFileFormatVersion)`
>> - `int flagsMask(ClassFileFormatVersion)`
>> 
>> Also there is some simplification to `AccessFlag` itself to remove the anonymous classes, which should be more startup-friendly.
>> 
>> Testing: Tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further enhance the impl of access flags, make cffv aware to flags easier

Weeks after weeks, this is not coming like project valhalla itself... This was opened in the beginning of a release cycle, yet no one reviewed; will this get deferred forever?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23095#issuecomment-2815970610

From bpb at openjdk.org  Fri Apr 18 18:24:56 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 18 Apr 2025 18:24:56 GMT
Subject: RFR: 8354450: Using a File with a path containing a trailing space
 should fail when alternative data streams are disabled (win) [v2]
In-Reply-To: 
References: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
 
 <1EKMYPzdR0EfG8v9_hauG3wPMw0_cRATLZlg0LbE4ps=.049a55bc-797a-4eb4-9b4a-f20b02cafbe4@github.com>
 
 <7LDV_FtSki03-PTPsSoobe3N-SbtcjVKzf933HBuFoQ=.474914b7-beda-4f80-8655-c0523bd23a87@github.com>
 
 
Message-ID: 

On Fri, 18 Apr 2025 08:11:28 GMT, Alan Bateman  wrote:

>> From experimentation with C++ code is VS, it appears that `CreateDirectoryW` will create a directory with either a leading or trailing space in its name, whereas `createFileW` will create a file with a leading space in its name, but a trailing space is trimmed.
>
>> From experimentation with C++ code is VS, it appears that `CreateDirectoryW` will create a directory with either a leading or trailing space in its name, whereas `createFileW` will create a file with a leading space in its name, but a trailing space is trimmed.
> 
> Right, the Windows APIs are very inconsistent on this, and why the Windows implementation of Path will always reject input where an element has a trailing space.

It turns out that a case such as `foo \bar\gus` already fails in `File.mkdirs` due to directory creation itself, so an explicit check for a trailing space in directory elements does not appear to be necessary, although having the failure occur in `isInvalid` would be more fail-fast.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24635#discussion_r2050965482

From duke at openjdk.org  Fri Apr 18 18:25:40 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 18 Apr 2025 18:25:40 GMT
Subject: RFR: 8077587: BigInteger Roots [v11]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  An optimization

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/e459c231..48650de2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=09-10

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From liach at openjdk.org  Fri Apr 18 18:25:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Apr 2025 18:25:54 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v2]
In-Reply-To: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
Message-ID: 

> Perf numbers for simple main:
> Linking of `Class::forName0` down from ~152 to ~83
> 
> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
> JNI: ~45
> baseline panama: ~164
> patch: ~103
> 
> Also see #24705.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Simplify FFM linker warmup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24742/files
  - new: https://git.openjdk.org/jdk/pull/24742/files/f9a0533f..dbf7799c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24742&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24742&range=00-01

  Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24742.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24742/head:pull/24742

PR: https://git.openjdk.org/jdk/pull/24742

From liach at openjdk.org  Fri Apr 18 18:35:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Apr 2025 18:35:40 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v2]
In-Reply-To: 
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 
 
 
Message-ID: 

On Fri, 18 Apr 2025 18:15:09 GMT, Jorn Vernee  wrote:

>> So just `Linker.nativeLinker().downcallHandle(MemorySegment.ofArray(new byte[0]), signature)` suffices?
>
> Yes, that would work, but I was thinking just `Linker.nativeLinker().downcallHandle(signature)`

Yep, simplified this, the startup results are still similar.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2050975328

From bpb at openjdk.org  Fri Apr 18 18:44:58 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 18 Apr 2025 18:44:58 GMT
Subject: RFR: 8354450: Using a File with a path containing a trailing space
 should fail when alternative data streams are disabled (win) [v3]
In-Reply-To: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
References: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
Message-ID: 

> In `java.io.WinNTFileSystem::isInvalid`, replace an insufficient test for file path validity with a sufficient test for file path invalidity. Also, add a new test.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8354450: Account for spaces in directory elements; update test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24635/files
  - new: https://git.openjdk.org/jdk/pull/24635/files/8c82d246..624f4f79

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24635&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24635&range=01-02

  Stats: 29 lines in 2 files changed: 21 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24635.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24635/head:pull/24635

PR: https://git.openjdk.org/jdk/pull/24635

From liach at openjdk.org  Fri Apr 18 19:03:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Apr 2025 19:03:51 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: 
References: 
Message-ID: <1BMZYXMCLuNxUcGFHy9U6TBYd1pChwilCjVOqXwHQT0=.8f352f4f-afec-40fb-90a5-5d1750b5fc45@github.com>

On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs  wrote:

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement 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.

src/java.net.http/share/classes/java/net/http/HttpRequest.java line 357:

> 355:          * @since TBD
> 356:          */
> 357:         public default  Builder setOption(HttpRequestOption option, T value) { return this; }

Bikeshed: we usually omit the set prefix for builders.

src/java.net.http/share/classes/java/net/http/HttpResponse.java line 838:

> 836:         /**
> 837:          * Represents a HTTP/3 PushID. PushIds can be shared across
> 838:          * multiple client initiated requests on the same HTTP/3 connection.

Is this a marker interface for various kinds of push ids? Otherwise just the record is sufficient.

src/java.net.http/share/classes/java/net/http/HttpResponse.java line 937:

> 935:                 HttpRequest initiatingRequest,
> 936:                 HttpRequest pushPromiseRequest,
> 937:                 PushId pushid,

(Warning: I know little about HTTP, my assumptions and thus whole argument may be invalid below!)

This feels like users need to use push ids as units of synchronization on this handler, such as tracking this with a ConcurrentHashMap.

Is it possible for users to instead provide a `Function` in `HttpClient::sendAsync`? I think this might make it easier for users as they no longer need to think about concurrency for different ids.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2050992217
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2050991104
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2051001758

From alanb at openjdk.org  Fri Apr 18 19:04:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 18 Apr 2025 19:04:46 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v5]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
Message-ID: 

On Fri, 18 Apr 2025 17:35:00 GMT, Stuart Marks  wrote:

> Line-oriented methods on Reader instead of BufferedReader.

I don't think a readLine would make sense for Reader but I think we can explore a method that reads all remaining characters (to EOS) as a sequence of lines. So a very different implementation to what is in BR now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2816033745

From rriggs at openjdk.org  Fri Apr 18 19:13:42 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 18 Apr 2025 19:13:42 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v5]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
Message-ID: 

On Thu, 17 Apr 2025 23:07:35 GMT, Brian Burkhalter  wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8354724: Increment copyright year in Reader
>  - 8354724: Move readString from BufferedReader to Reader

Without over-rotating on performance concerns, use `readString()` as currently specified and defer to `String.lines()` to produce the Stream of lines, or `String.lines().toList()` for a List.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2816045724

From bpb at openjdk.org  Fri Apr 18 19:39:42 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 18 Apr 2025 19:39:42 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v5]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
 
Message-ID: 

On Fri, 18 Apr 2025 19:02:26 GMT, Alan Bateman  wrote:

> I don't think a readLine would make sense for Reader

If there were a `readLine` I would expect it not to be exposed in the API.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2816085214

From abakhtin at openjdk.org  Fri Apr 18 19:48:45 2025
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Fri, 18 Apr 2025 19:48:45 GMT
Subject: RFR: 8259540: MissingResourceException for key
 cvc-complex-type.2.4.d.1
In-Reply-To: 
References: 
 
 
Message-ID: <5Dl6Me90o2xhB7xeVWteL_AXT9KpNBg_rjUr1AJEOoU=.278bac2c-8504-4ccd-803c-165c61a0f5be@github.com>

On Fri, 18 Apr 2025 17:40:10 GMT, Joe Wang  wrote:

>> Added missed localized strings for _de, _ja and _zh_CN localities based on the JDK11 localizations
>
>> Added missed localized strings for _de, _ja and _zh_CN localities based on the JDK11 localizations
> 
> Probably not necessary as they will be covered by L10n resource update.

Sorry, I didn't know about L10n resource updates. @JoeWang-Java, do you suggest removing localizations and waiting for "JDK 25 RDP1 L10n resource files update" in June?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24747#issuecomment-2816095207

From naoto at openjdk.org  Fri Apr 18 20:09:45 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 18 Apr 2025 20:09:45 GMT
Subject: RFR: 8354774: DocumentBuilderFactory getAttribute throws NPE
In-Reply-To: 
References: 
Message-ID: <9XheF_X0RnLcGYKBxhWDg8aVbmGsaxN2MdLf0tSdu7g=.f63a0bf4-4e8a-456d-9368-c38d70dfb110@github.com>

On Thu, 17 Apr 2025 17:41:56 GMT, Joe Wang  wrote:

> Fix a NPE on calling DocumentBuilderFactory::getAttribute. This issue was found during the previous JCK test (JCK-7322355). The JCK failure was from a different method call, but it appears this is the root cause.
> 
> Also in this patch: consolidates get and set properties to use the same Util methods to reduce potential errors when code changes.
> 
> Test:
>     Tier1 - 3 passed
>     JCK test passed (will update JCK-7322355 once this patch is integrated)

Looks good to me. Some minor comments follow

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/PropertyManager.java line 261:

> 259:                 //fall back to the existing property manager
> 260:                 supportedProps.put(property, value);
> 261:             }

`JdkProperty` and `FeaturePropertyBase` can be removed from `import`. Applies to other sources as well

src/java.xml/share/classes/jdk/xml/internal/JdkXmlUtils.java line 112:

> 110:     public static boolean setProperty(XMLSecurityManager xsm, XMLSecurityPropertyManager xspm,
> 111:             String property, Object value) {
> 112:         String pName;

`pName` is not needed

-------------

PR Review: https://git.openjdk.org/jdk/pull/24732#pullrequestreview-2779317350
PR Review Comment: https://git.openjdk.org/jdk/pull/24732#discussion_r2051066519
PR Review Comment: https://git.openjdk.org/jdk/pull/24732#discussion_r2051056587

From bpb at openjdk.org  Fri Apr 18 20:10:32 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 18 Apr 2025 20:10:32 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v6]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: 

> Implement the requested methods and add a test thereof.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8354724: Remove unused import

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/8b0b9238..b9424bb4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728

PR: https://git.openjdk.org/jdk/pull/24728

From liach at openjdk.org  Fri Apr 18 20:38:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Apr 2025 20:38:14 GMT
Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to class
 file version
Message-ID: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>

Take the class file version to reject flags not yet defined, redefined, or obsoleted. The non-cffv version can return the preview flags when the current runtime is in preview.

-------------

Depends on: https://git.openjdk.org/jdk/pull/23095

Commit messages:
 - 8297271: AccessFlag.maskToAccessFlags should be specific to class file version

Changes: https://git.openjdk.org/jdk/pull/24760/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24760&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297271
  Stats: 157 lines in 9 files changed: 93 ins; 31 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/24760.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24760/head:pull/24760

PR: https://git.openjdk.org/jdk/pull/24760

From bpb at openjdk.org  Fri Apr 18 20:45:47 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 18 Apr 2025 20:45:47 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v5]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
Message-ID: 

On Fri, 18 Apr 2025 19:11:15 GMT, Roger Riggs  wrote:

> Without over-rotating on performance concerns, [...]

Or just for the sake of silliness:

    public List readAllLines() throws IOException {
        String regex = "(?:\n)|(?:\r)|\r(?=\n)";
        return Arrays.asList(readString().split(regex));
    }


(My regex knowledge is poor so that might not even be correct.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2816164684

From joehw at openjdk.org  Fri Apr 18 21:26:23 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 18 Apr 2025 21:26:23 GMT
Subject: RFR: 8354774: DocumentBuilderFactory getAttribute throws NPE [v2]
In-Reply-To: 
References: 
Message-ID: <0bAwDMoPMDTI66jUMmkU_Fo7oEW4XYIGbkYnJz3jK74=.991ad888-be65-422e-a2fd-b702fff5c437@github.com>

> Fix a NPE on calling DocumentBuilderFactory::getAttribute, refer to the bug report.
> 
> Also in this patch: consolidates get and set properties to use the same Util methods to reduce potential errors when code changes.
> 
> Test:
>     Tier1 - 3 passed
>     JCK test passed

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  remove unused variable pName; remove unused imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24732/files
  - new: https://git.openjdk.org/jdk/pull/24732/files/8606921c..1b8ecd32

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24732&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24732&range=00-01

  Stats: 7 lines in 3 files changed: 0 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24732/head:pull/24732

PR: https://git.openjdk.org/jdk/pull/24732

From joehw at openjdk.org  Fri Apr 18 21:26:23 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 18 Apr 2025 21:26:23 GMT
Subject: RFR: 8354774: DocumentBuilderFactory getAttribute throws NPE [v2]
In-Reply-To: <9XheF_X0RnLcGYKBxhWDg8aVbmGsaxN2MdLf0tSdu7g=.f63a0bf4-4e8a-456d-9368-c38d70dfb110@github.com>
References: 
 <9XheF_X0RnLcGYKBxhWDg8aVbmGsaxN2MdLf0tSdu7g=.f63a0bf4-4e8a-456d-9368-c38d70dfb110@github.com>
Message-ID: 

On Fri, 18 Apr 2025 20:06:01 GMT, Naoto Sato  wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove unused variable pName; remove unused imports
>
> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/PropertyManager.java line 261:
> 
>> 259:                 //fall back to the existing property manager
>> 260:                 supportedProps.put(property, value);
>> 261:             }
> 
> `JdkProperty` and `FeaturePropertyBase` can be removed from `import`. Applies to other sources as well

Removed unused imports in classes affected in this patch. Thanks.

> src/java.xml/share/classes/jdk/xml/internal/JdkXmlUtils.java line 112:
> 
>> 110:     public static boolean setProperty(XMLSecurityManager xsm, XMLSecurityPropertyManager xspm,
>> 111:             String property, Object value) {
>> 112:         String pName;
> 
> `pName` is not needed

Removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24732#discussion_r2051139824
PR Review Comment: https://git.openjdk.org/jdk/pull/24732#discussion_r2051139530

From asemenyuk at openjdk.org  Fri Apr 18 21:36:28 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 18 Apr 2025 21:36:28 GMT
Subject: RFR: 8354990: Improve negative tests coverage for jpackage signing
Message-ID: 

Add tests for the following test cases:
 - Expired certificate specified for signing;
 - Multiple certificates with the same name in one keychain.

Adding the new tests revealed an issue with MacCertificate - [JDK-8354989](https://bugs.openjdk.org/browse/JDK-8354989). This issue is also addressed in this PR.

Additionally:
 - Moved code to verify signatures in MacSignVerify class and reworked SigningBase verify functions to use MacSignVerify API.

-------------

Commit messages:
 - Trailing whitespace clean up
 - Make SigningBase use MacSignVerify for signatures verification
 - Add MacSignTest.testSelectSigningIdentity() to cover cases when full signing identity name is specified.
 -  - Add expired certificates to SigningBase. Add standard certificate prefixes to MacSign.
 - Support expired certificates. Support multiple SHA in MacSign.CertificateHash
 - Add MacVerifySign
 - MacCertificate: bugfix

Changes: https://git.openjdk.org/jdk/pull/24762/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24762&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354990
  Stats: 955 lines in 7 files changed: 717 ins; 134 del; 104 mod
  Patch: https://git.openjdk.org/jdk/pull/24762.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24762/head:pull/24762

PR: https://git.openjdk.org/jdk/pull/24762

From naoto at openjdk.org  Fri Apr 18 21:39:55 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 18 Apr 2025 21:39:55 GMT
Subject: RFR: 8354774: DocumentBuilderFactory getAttribute throws NPE [v2]
In-Reply-To: <0bAwDMoPMDTI66jUMmkU_Fo7oEW4XYIGbkYnJz3jK74=.991ad888-be65-422e-a2fd-b702fff5c437@github.com>
References: 
 <0bAwDMoPMDTI66jUMmkU_Fo7oEW4XYIGbkYnJz3jK74=.991ad888-be65-422e-a2fd-b702fff5c437@github.com>
Message-ID: 

On Fri, 18 Apr 2025 21:26:23 GMT, Joe Wang  wrote:

>> Fix a NPE on calling DocumentBuilderFactory::getAttribute, refer to the bug report.
>> 
>> Also in this patch: consolidates get and set properties to use the same Util methods to reduce potential errors when code changes.
>> 
>> Test:
>>     Tier1 - 3 passed
>>     JCK test passed
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused variable pName; remove unused imports

Thanks. Looks good.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24732#pullrequestreview-2779478771

From vlivanov at openjdk.org  Fri Apr 18 21:41:42 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 18 Apr 2025 21:41:42 GMT
Subject: RFR: 8354300: Fields in String are not trusted
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Apr 2025 14:47:59 GMT, Per Minborg  wrote:

> This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and `j.l.String.hashIsZero`. This means the VM can trust these fields to never change which enables constant folding optimizations.
> 
> This PR is tested in tier1, tier2, tier3, and tier4 which all pass.

Looks fine.

Bug summary is misleading though (all fields in java.lang package *are* trusted from JVM POV). Please, change it (e.g., "Mark String.hash field stable").

-------------

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24625#pullrequestreview-2779480984

From joehw at openjdk.org  Fri Apr 18 21:50:46 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 18 Apr 2025 21:50:46 GMT
Subject: RFR: 8259540: MissingResourceException for key
 cvc-complex-type.2.4.d.1
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 18 Apr 2025 17:40:10 GMT, Joe Wang  wrote:

>> Added missed localized strings for _de, _ja and _zh_CN localities based on the JDK11 localizations
>
>> Added missed localized strings for _de, _ja and _zh_CN localities based on the JDK11 localizations
> 
> Probably not necessary as they will be covered by L10n resource update.

> Sorry, I didn't know about L10n resource updates. @JoeWang-Java, do you suggest removing localizations and waiting for "JDK 25 RDP1 L10n resource files update" in June?

Yes, I would. I removed resource files other than English from my previous PR as well after getting reviewers' suggestions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24747#issuecomment-2816244094

From liach at openjdk.org  Fri Apr 18 22:14:23 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Apr 2025 22:14:23 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v5]
In-Reply-To: 
References: 
Message-ID: 

> Some AccessFlag parsing methods throw IAE because a flag mask is not valid in a location. However, there is no easy way to check what flag mask bits or what flags are valid for a location. We need such APIs to check, specific to each class file format version.
> 
> Also in the investigation, it's noted that `ACC_SYNTHETIC` is incorrectly represented - it is available since release 5.0 instead of release 7. This bug is fixed together for implementation simplicity.
> 
> The new methods are all in `AccessFlag.Location`:
> - `Set flags()`
> - `int flagsMask()`
> - `Set flags(ClassFileFormatVersion)`
> - `int flagsMask(ClassFileFormatVersion)`
> 
> Also there is some simplification to `AccessFlag` itself to remove the anonymous classes, which should be more startup-friendly.
> 
> Testing: Tier 1-3

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Preview notes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23095/files
  - new: https://git.openjdk.org/jdk/pull/23095/files/303edd90..7e6d58a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23095&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23095&range=03-04

  Stats: 44 lines in 1 file changed: 36 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23095.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23095/head:pull/23095

PR: https://git.openjdk.org/jdk/pull/23095

From abakhtin at openjdk.org  Fri Apr 18 22:15:10 2025
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Fri, 18 Apr 2025 22:15:10 GMT
Subject: RFR: 8259540: MissingResourceException for key
 cvc-complex-type.2.4.d.1 [v3]
In-Reply-To: 
References: 
Message-ID: <-qCChAf9d5xERBjm88WrJi_adXPaPoE69G4M9TSn_aA=.b36f8cf8-8443-4c41-8083-203de74d003b@github.com>

> Please find a trivial fix for the missing `cvc-complex-type.2.4.d.1` resource in the main XMLSchemaMessages.properties file.

Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:

  Backout "Add locolizations for _de, _ja and _zh_CN"
  
  This reverts commit 3ad1f7f7cf00ce2f13f3f6305299c5c09a6b4e25.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24747/files
  - new: https://git.openjdk.org/jdk/pull/24747/files/3ad1f7f7..c555a125

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24747&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24747&range=01-02

  Stats: 3 lines in 3 files changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24747.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24747/head:pull/24747

PR: https://git.openjdk.org/jdk/pull/24747

From duke at openjdk.org  Fri Apr 18 23:31:25 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 18 Apr 2025 23:31:25 GMT
Subject: RFR: 8077587: BigInteger Roots [v12]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  BigIntegers nth root's initial estimate optimization

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/48650de2..54ec8f85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=10-11

  Stats: 28 lines in 1 file changed: 23 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From joehw at openjdk.org  Fri Apr 18 23:33:41 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 18 Apr 2025 23:33:41 GMT
Subject: RFR: 8259540: MissingResourceException for key
 cvc-complex-type.2.4.d.1 [v3]
In-Reply-To: <-qCChAf9d5xERBjm88WrJi_adXPaPoE69G4M9TSn_aA=.b36f8cf8-8443-4c41-8083-203de74d003b@github.com>
References: 
 <-qCChAf9d5xERBjm88WrJi_adXPaPoE69G4M9TSn_aA=.b36f8cf8-8443-4c41-8083-203de74d003b@github.com>
Message-ID: 

On Fri, 18 Apr 2025 22:15:10 GMT, Alexey Bakhtin  wrote:

>> Please find a trivial fix for the missing `cvc-complex-type.2.4.d.1` resource in the main XMLSchemaMessages.properties file.
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Backout "Add locolizations for _de, _ja and _zh_CN"
>   
>   This reverts commit 3ad1f7f7cf00ce2f13f3f6305299c5c09a6b4e25.

Looks good. Thanks.

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24747#pullrequestreview-2779619451

From abakhtin at openjdk.org  Sat Apr 19 00:33:44 2025
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Sat, 19 Apr 2025 00:33:44 GMT
Subject: Integrated: 8259540: MissingResourceException for key
 cvc-complex-type.2.4.d.1
In-Reply-To: 
References: 
Message-ID: <_Zfw4Rkix1DkumsB6idwoNrU6v2oIGRf7y2cCVHuy-w=.6b359d57-8dac-439f-ab3c-57f7dd198261@github.com>

On Fri, 18 Apr 2025 04:08:56 GMT, Alexey Bakhtin  wrote:

> Please find a trivial fix for the missing `cvc-complex-type.2.4.d.1` resource in the main XMLSchemaMessages.properties file.

This pull request has now been integrated.

Changeset: 4f58af0a
Author:    Alexey Bakhtin 
URL:       https://git.openjdk.org/jdk/commit/4f58af0a8dd5eced77259bed180f6af36501f502
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8259540: MissingResourceException for key cvc-complex-type.2.4.d.1

Reviewed-by: joehw

-------------

PR: https://git.openjdk.org/jdk/pull/24747

From jpai at openjdk.org  Sat Apr 19 01:28:49 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 19 Apr 2025 01:28:49 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine [v2]
In-Reply-To: 
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
 
Message-ID: 

On Thu, 17 Apr 2025 20:51:10 GMT, Chen Liang  wrote:

>> When jdeps was migrated from old classfile to ClassFile API, the parsing semantic changed - error checks are now made lazily, and nested crashes from malformed signature or other problems is now latent, after a `ClassModel` instance is available. (The old error check existed only for constructing a `ClassModel`)
>> 
>> To address this issue, I have updated the way of iterating class files to be handler/consumer based like in the ClassFile API. This has the advantage that when one invocation of the handler fails of a `ClassFileError`, other invocations for other class files can proceed, and the exception handler has sufficient information to report a useful message indicating the source of error.
>> 
>> For the particular example of examining a proguard processed `dummy-scala.jar`, here is the new output of `jdeps dummy-scala.jar`:
>> 
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 59, expected an identifier: Lscala/collection/immutable/TreeMap$TreeMapBuilder.;: scala/collection/immutable/TreeMap$TreeMapBuilder.class (dummy-scala.jar)
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 49, expected an identifier: Lscala/collection/parallel/mutable/ParArray.;: scala/collection/parallel/mutable/ParArray.class (dummy-scala.jar)
>> 
>> 
>> Now, jdeps shows the bad class files. Inspection into the files reveal that proguard incorrectly deleted the simple class names with trailing `$`, for example, the original signature of the broken ParArray was `Lscala/collection/parallel/mutable/ParArray.ParArrayIterator$;`, so the `ParArrayIterator$` part was incorrectly dropped by proguard.
>> 
>> Testing: langtools/tools/jdeps.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks

I don't have knowledge of this tool's implementation but given the issue, these changes seem reasonable to me. I think there should be a regression test included to reproduce the issue and verify the fix.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24604#pullrequestreview-2779732218

From liach at openjdk.org  Sat Apr 19 01:58:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 19 Apr 2025 01:58:54 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine [v2]
In-Reply-To: 
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
 
Message-ID: 

On Thu, 17 Apr 2025 20:51:10 GMT, Chen Liang  wrote:

>> When jdeps was migrated from old classfile to ClassFile API, the parsing semantic changed - error checks are now made lazily, and nested crashes from malformed signature or other problems is now latent, after a `ClassModel` instance is available. (The old error check existed only for constructing a `ClassModel`)
>> 
>> To address this issue, I have updated the way of iterating class files to be handler/consumer based like in the ClassFile API. This has the advantage that when one invocation of the handler fails of a `ClassFileError`, other invocations for other class files can proceed, and the exception handler has sufficient information to report a useful message indicating the source of error.
>> 
>> For the particular example of examining a proguard processed `dummy-scala.jar`, here is the new output of `jdeps dummy-scala.jar`:
>> 
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 59, expected an identifier: Lscala/collection/immutable/TreeMap$TreeMapBuilder.;: scala/collection/immutable/TreeMap$TreeMapBuilder.class (dummy-scala.jar)
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 49, expected an identifier: Lscala/collection/parallel/mutable/ParArray.;: scala/collection/parallel/mutable/ParArray.class (dummy-scala.jar)
>> 
>> 
>> Now, jdeps shows the bad class files. Inspection into the files reveal that proguard incorrectly deleted the simple class names with trailing `$`, for example, the original signature of the broken ParArray was `Lscala/collection/parallel/mutable/ParArray.ParArrayIterator$;`, so the `ParArrayIterator$` part was incorrectly dropped by proguard.
>> 
>> Testing: langtools/tools/jdeps.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks

Unfortunately, I don't think there is a convenient way to make a jar  with jtreg tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24604#issuecomment-2816458196

From duke at openjdk.org  Sat Apr 19 06:30:51 2025
From: duke at openjdk.org (ExE Boss)
Date: Sat, 19 Apr 2025 06:30:51 GMT
Subject: RFR: 8354300: Fields in String are not trusted
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 14 Apr 2025 18:09:35 GMT, Chen Liang  wrote:

>> Hello Per, I'm not too familiar with runtime compiler optimizations. So consider this as a basic question. 
>> 
>>> This means the VM can trust these fields to never change which enables constant folding optimizations.
>> 
>> If I'm not wrong, then it is the `hash` field value that we want to be considered as a constant (once computed) so that calls to `String.hashCode()` would get replaced with the constant computed value.
>> 
>> Looking at the current implementation of `String.hashCode()`:
>> 
>> 
>> public int hashCode() {
>>         // The hash or hashIsZero fields are subject to a benign data race,
>>         // making it crucial to ensure that any observable result of the
>>         // calculation in this method stays correct under any possible read of
>>         // these fields. Necessary restrictions to allow this to be correct
>>         // without explicit memory fences or similar concurrency primitives is
>>         // that we can ever only write to one of these two fields for a given
>>         // String instance, and that the computation is idempotent and derived
>>         // from immutable state
>>         int h = hash;
>>         if (h == 0 && !hashIsZero) {
>>             h = isLatin1() ? StringLatin1.hashCode(value)
>>                            : StringUTF16.hashCode(value);
>>             if (h == 0) {
>>                 hashIsZero = true;
>>             } else {
>>                 hash = h;
>>             }
>>         }
>>         return h;
>>     }
>> 
>> 
>> If I'm reading that correctly, and keeping aside concurrent calls from this discussion, then only one of `hash` or the `hashIsZero` fields will have its value changed to a non-default value. i.e. if `hashCode()` implementation computes a non-zero value then the `hash` field will be assigned a (non-default) value and if that method computes a hash of 0, then `hashIsZero` will get assigned a (non-default) value. It then means that the other field will never move out of its initial value and thus will never be considered "stable".
>> 
>> Am I right? If yes, then would the runtime (hotspot) compiler still replace the call to `String.hashCode()` with a constant value?
>
> Also re @jaikiran: yes, you are right that the current code cannot constant-fold the scenario where the hash is 0; so `"".hashCode()` is not constant as a result. The solution I shared above can address this scenario, but it cannot completely bring performance to parity with other constant-folded cases in Remi's shared benchmark (see https://github.com/liachmodded/jdk/commit/247e8bd92e6dbad6df2dd50ad83caa49983a81b4)

@liach
> ```java
> var isZero = hashIsZero;
> if (isZero == 1) return 0;
> if (isZero == 2) {
> 	int h = hash;
> 	if (h != 0) return h;
> }
> return computeHash(); // and set hash, hashIsZero fields
> ```

Instead?of `hashIsZero`, the?field should?be?called `hashState` in?that?case.

And?maybe use?`-1` for?the?`hashCode() ==?0`?state and?`+1` for?the?`hashCode() !=?0`?state.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24625#issuecomment-2816567930

From duke at openjdk.org  Sat Apr 19 08:32:32 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 19 Apr 2025 08:32:32 GMT
Subject: RFR: 8077587: BigInteger Roots [v13]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Extend use cases of MutableBigInteger.valueOf(double)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/54ec8f85..3ea51902

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=11-12

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From duke at openjdk.org  Sat Apr 19 08:56:40 2025
From: duke at openjdk.org (ExE Boss)
Date: Sat, 19 Apr 2025 08:56:40 GMT
Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to
 class file version
In-Reply-To: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
Message-ID: 

On Fri, 18 Apr 2025 20:33:27 GMT, Chen Liang  wrote:

> Take the class file version to reject flags not yet defined, redefined, or obsoleted. The non-cffv version can return the preview flags when the current runtime is in preview.

With?this, the?**Class?File API**?needs to?be?updated to?pass the?current class?file format?version to?the?calls of?`AccessFlag?.maskToAccessFlags(?)`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24760#issuecomment-2816617102

From duke at openjdk.org  Sat Apr 19 09:44:31 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 19 Apr 2025 09:44:31 GMT
Subject: RFR: 8077587: BigInteger Roots [v14]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  An optimization

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/3ea51902..6c9b364e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=12-13

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From duke at openjdk.org  Sat Apr 19 09:59:24 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 19 Apr 2025 09:59:24 GMT
Subject: RFR: 8077587: BigInteger Roots [v15]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  An optimization

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/6c9b364e..3ca7d29c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=13-14

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From liach at openjdk.org  Sat Apr 19 15:06:45 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 19 Apr 2025 15:06:45 GMT
Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to
 class file version
In-Reply-To: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
Message-ID: 

On Fri, 18 Apr 2025 20:33:27 GMT, Chen Liang  wrote:

> Take the class file version to reject flags not yet defined, redefined, or obsoleted. The non-cffv version can return the preview flags when the current runtime is in preview.

That is tracked in a separate bug linked as a dependent on this issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24760#issuecomment-2816742550

From duke at openjdk.org  Sat Apr 19 15:23:25 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 19 Apr 2025 15:23:25 GMT
Subject: RFR: 8077587: BigInteger Roots [v16]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Format code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/3ca7d29c..4516d88d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=14-15

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From duke at openjdk.org  Sat Apr 19 15:25:54 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 19 Apr 2025 15:25:54 GMT
Subject: RFR: 8077587: BigInteger Roots [v17]
In-Reply-To: 
References: 
Message-ID: <3HxtfzEDHOjSNcQbDOkUUs-u6rxvd1gQQJcNAcsWsfY=.b0c49212-bd34-4187-8ec1-d638a0577b97@github.com>

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Format code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/4516d88d..b427091f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=15-16

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From duke at openjdk.org  Sat Apr 19 19:23:26 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 19 Apr 2025 19:23:26 GMT
Subject: RFR: 8077587: BigInteger Roots [v18]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 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 21 additional commits since the last revision:

 - Merge branch 'openjdk:master' into BigInteger-nth-root
 - Format code
 - Format code
 - An optimization
 - An optimization
 - Extend use cases of MutableBigInteger.valueOf(double)
 - BigIntegers nth root's initial estimate optimization
 - An optimization
 - Memory usage optimization
 - Correct left shift if shift is zero
 - ... and 11 more: https://git.openjdk.org/jdk/compare/29bccfda...524f195e

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/b427091f..524f195e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=16-17

  Stats: 11487 lines in 264 files changed: 9970 ins; 920 del; 597 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From mli at openjdk.org  Sat Apr 19 20:09:59 2025
From: mli at openjdk.org (Hamlin Li)
Date: Sat, 19 Apr 2025 20:09:59 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L [v9]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> Can you help to review this patch?
> On riscv, CMoveI/L already were implemented, but there are some gap:
> 1. CMoveI/L does not support comparison with float/double, corresponding tests are not turn on either.
> 2. Some optimization of C2 is not turned on, e.g. `Phi -> CMove -> min_max`.
> 3. lack of some corresponding performance tests.
> 
> Also there are some issue with current Zicond:
> 1. UseZicond is turned on automatically by hwprobe, but jmh tests show that it's not always bring benefit, in some situation it even brings regression, the reason is the generated code by Zicond is much larger than branch version, in particular when it's in a loop and unrolled.
> 
> This patch on riscv is to:
> 1. add CMoveI/L comparing float/double, and corresponding tests,
> 2. enable more C2 optimization,
> 3. add more benchmark tests,
> 4. turn off UseZicond by default.
> 
> Thanks!
> 
> ## Performance
> 
> ### MinMax
> test data
> 
> Benchmark | Mode | Cnt | Score - master | Score - master+UseZbb | Score - -master+UseZicond | Score - master+UseZicond+UseZbb | Score - cmovei | Score - cmovei+UseZbb | Score - cmovei+UseZicond | Score - cmovei+UseZicond+UseZbb | Error | Units | Opt (master/cmovei)
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> o.o.b.vm.compiler.IfMinMax.testReductionInt | avgt | 40 | 17152.075 | 17216.592 | 17272.493 | 17296.89 | 17127.844 | 17036.605 | 17299.333 | 17250.566 | 73.179 | ns/op | 1.001
> o.o.b.vm.compiler.IfMinMax.testReductionLong | avgt | 40 | 19770.828 | 19967.578 | 20268.905 | 20166.165 | 20065.552 | 20059.095 | 20161.914 | 20151.295 | 131.428 | ns/op | 0.985
> o.o.b.vm.compiler.IfMinMax.testSingleInt | avgt | 40 | 114.734 | 114.402 | 114.887 | 114.384 | 114.4 | 110.631 | 112.162 | 110.915 | 0.333 | ns/op | 1.003
> o.o.b.vm.compiler.IfMinMax.testSingleLong | avgt | 40 | 121.53 | 121.711 | 120.91 | 121.665 | 121.309 | 120.57 | 118.639 | 119.373 | 0.451 | ns/op | 1.002
> o.o.b.vm.compiler.IfMinMax.testVectorInt | avgt | 40 | 60130.165 | 60062.303 | 61839.776 | 61895.194 | 15887.398 | 15924.502 | 15874.835 | 15667.936 | 101.94 | ns/op | 3.785
> o.o.b.vm.compiler.IfMinMax.testVectorLong | avgt | 40 | 63855.379 | 6309...

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24490/files
  - new: https://git.openjdk.org/jdk/pull/24490/files/67fd2681..3bcc7c8a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24490&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24490&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24490/head:pull/24490

PR: https://git.openjdk.org/jdk/pull/24490

From mli at openjdk.org  Sat Apr 19 20:09:59 2025
From: mli at openjdk.org (Hamlin Li)
Date: Sat, 19 Apr 2025 20:09:59 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L [v8]
In-Reply-To: <0exy0s0on9e274HN29ECdNuB9D8_vwcW6plafjgXDMc=.c3ff7043-52b5-43c3-b488-8062b0178d29@github.com>
References: 
 
 <0exy0s0on9e274HN29ECdNuB9D8_vwcW6plafjgXDMc=.c3ff7043-52b5-43c3-b488-8062b0178d29@github.com>
Message-ID: 

On Wed, 16 Apr 2025 00:05:44 GMT, Fei Yang  wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minors
>
> test/hotspot/jtreg/compiler/vectorapi/TestVectorTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2022, 2025,Oracle and/or its affiliates. All rights reserved.
> 
> The jcheck is complaining about a copyright format issue here. There should be a space after `2025,`.

Thanks! Let me fix it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24490#discussion_r2051571194

From fyang at openjdk.org  Sun Apr 20 01:19:53 2025
From: fyang at openjdk.org (Fei Yang)
Date: Sun, 20 Apr 2025 01:19:53 GMT
Subject: RFR: 8352504: RISC-V: implement and enable CMoveI/L [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 19 Apr 2025 20:09:59 GMT, Hamlin Li  wrote:

>> Hi,
>> Can you help to review this patch?
>> On riscv, CMoveI/L already were implemented, but there are some gap:
>> 1. CMoveI/L does not support comparison with float/double, corresponding tests are not turn on either.
>> 2. Some optimization of C2 is not turned on, e.g. `Phi -> CMove -> min_max`.
>> 3. lack of some corresponding performance tests.
>> 
>> Also there are some issue with current Zicond:
>> 1. UseZicond is turned on automatically by hwprobe, but jmh tests show that it's not always bring benefit, in some situation it even brings regression, the reason is the generated code by Zicond is much larger than branch version, in particular when it's in a loop and unrolled.
>> 
>> This patch on riscv is to:
>> 1. add CMoveI/L comparing float/double, and corresponding tests,
>> 2. enable more C2 optimization,
>> 3. add more benchmark tests,
>> 4. turn off UseZicond by default.
>> 
>> Thanks!
>> 
>> ## Performance
>> 
>> ### MinMax
>> test data
>> 
>> Benchmark | Mode | Cnt | Score - master | Score - master+UseZbb | Score - -master+UseZicond | Score - master+UseZicond+UseZbb | Score - cmovei | Score - cmovei+UseZbb | Score - cmovei+UseZicond | Score - cmovei+UseZicond+UseZbb | Error | Units | Opt (master/cmovei)
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> o.o.b.vm.compiler.IfMinMax.testReductionInt | avgt | 40 | 17152.075 | 17216.592 | 17272.493 | 17296.89 | 17127.844 | 17036.605 | 17299.333 | 17250.566 | 73.179 | ns/op | 1.001
>> o.o.b.vm.compiler.IfMinMax.testReductionLong | avgt | 40 | 19770.828 | 19967.578 | 20268.905 | 20166.165 | 20065.552 | 20059.095 | 20161.914 | 20151.295 | 131.428 | ns/op | 0.985
>> o.o.b.vm.compiler.IfMinMax.testSingleInt | avgt | 40 | 114.734 | 114.402 | 114.887 | 114.384 | 114.4 | 110.631 | 112.162 | 110.915 | 0.333 | ns/op | 1.003
>> o.o.b.vm.compiler.IfMinMax.testSingleLong | avgt | 40 | 121.53 | 121.711 | 120.91 | 121.665 | 121.309 | 120.57 | 118.639 | 119.373 | 0.451 | ns/op | 1.002
>> o.o.b.vm.compiler.IfMinMax.testVectorInt | avgt | 40 | 60130.165 | 60062.303 | 61839.776 | 61895.194 | 15887.398 | 15924.502 | 15874.835 | 15667.936 | 101.94 | ns/op | 3.785
>> o.o.b.vm.c...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

Marked as reviewed by fyang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24490#pullrequestreview-2780122465

From syan at openjdk.org  Sun Apr 20 03:07:48 2025
From: syan at openjdk.org (SendaoYan)
Date: Sun, 20 Apr 2025 03:07:48 GMT
Subject: RFR: 8354774: DocumentBuilderFactory getAttribute throws NPE [v2]
In-Reply-To: <0bAwDMoPMDTI66jUMmkU_Fo7oEW4XYIGbkYnJz3jK74=.991ad888-be65-422e-a2fd-b702fff5c437@github.com>
References: 
 <0bAwDMoPMDTI66jUMmkU_Fo7oEW4XYIGbkYnJz3jK74=.991ad888-be65-422e-a2fd-b702fff5c437@github.com>
Message-ID: 

On Fri, 18 Apr 2025 21:26:23 GMT, Joe Wang  wrote:

>> Fix a NPE on calling DocumentBuilderFactory::getAttribute, refer to the bug report.
>> 
>> Also in this patch: consolidates get and set properties to use the same Util methods to reduce potential errors when code changes.
>> 
>> Test:
>>     Tier1 - 3 passed
>>     JCK test passed
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused variable pName; remove unused imports

Changes requested by syan (Committer).

test/jaxp/javax/xml/jaxp/unittest/common/PropertiesTest.java line 47:

> 45:  * @summary Verifies JAXP API Properties as specified in the java.xml module.
> 46:  * @library /javax/xml/jaxp/libs /javax/xml/jaxp/unittest /test/lib
> 47:  * @run junit/othervm common.PropertiesTest

`/othervm` seems do not needed

-------------

PR Review: https://git.openjdk.org/jdk/pull/24732#pullrequestreview-2780134426
PR Review Comment: https://git.openjdk.org/jdk/pull/24732#discussion_r2051623145

From syan at openjdk.org  Sun Apr 20 03:31:40 2025
From: syan at openjdk.org (SendaoYan)
Date: Sun, 20 Apr 2025 03:31:40 GMT
Subject: RFR: 8351623: VectorAPI: Refactor subword gather load and add SVE
 implementation
In-Reply-To: 
References: 
Message-ID: 

On Wed, 16 Apr 2025 08:58:34 GMT, Xiaohong Gong  wrote:

> ### Summary:
> [JDK-8318650](http://java-service.client.nvidia.com/?q=8318650) added the hotspot intrinsifying of subword gather load APIs for X86 platforms [1]. This patch aims at implementing the equivalent functionality for AArch64 SVE platform. In addition to the AArch64 backend support, this patch also refactors the API implementation in Java side and the compiler mid-end part to make the operations more efficient and maintainable across different architectures.
> 
> ### Background:
> Vector gather load APIs load values from memory addresses calculated by adding a base pointer to integer indices stored in an int array. SVE provides native vector gather load instructions for byte/short types using an int vector saving indices (see [2][3]).
> 
> The number of loaded elements must match the index vector's element count. Since int elements are 4/2 times larger than byte/short elements, and given `MaxVectorSize` constraints, the operation may need to be splitted into multiple parts.
> 
> Using a 128-bit byte vector gather load as an example, there are four scenarios with different `MaxVectorSize`:
> 
> 1. `MaxVectorSize = 16, byte_vector_size = 16`:
>    - Can load 4 indices per vector register
>    - So can finish 4 bytes per gather-load operation
>    - Requires 4 times of gather-loads and final merge
>    Example:
>    ```
>    byte[] arr = [a, b, c, d, e, f, g, h, i, g, k, l, m, n, o, p, ...]
>    int[] idx = [3, 2, 4, 1, 5, 7, 5, 2, 0, 6, 7, 1, 15, 10, 11, 9]
> 
>    4 gather-load:
>    idx_v1 = [1 4 2 3]    gather_v1 = [0000 0000 0000 becd]
>    idx_v2 = [2 5 7 5]    gather_v2 = [0000 0000 0000 cfhf]
>    idx_v3 = [1 7 6 0]    gather_v3 = [0000 0000 0000 bhga]
>    idx_v4 = [9 11 10 15] gather_v4 = [0000 0000 0000 jlkp]
>    merge: v = [jlkp bhga cfhf becd]
>    ```
> 
> 2. `MaxVectorSize = 32, byte_vector_size = MaxVectorSize / 2`:
>    - Can load 8 indices per vector register
>    - So can finish 8 bytes per gather-load operation
>    - Requires 2 times of gather-loads and merge
>    Example:
>    ```
>    byte[] arr = [a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, ...]
>    int[] index = [3, 2, 4, 1, 5, 7, 5, 2, 0, 6, 7, 1, 15, 10, 11, 9]
> 
>    2 gather-load:
>    idx_v1 = [2 5 7 5 1 4 2 3]
>    idx_v2 = [9 11 10 15 1 7 6 0]
>    gather_v1 = [0000 0000 0000 0000 0000 0000 cfhf becd]
>    gather_v2 = [0000 0000 0000 0000 0000 0000 jlkp bhga]
>    merge: v = [0000 0000 0000 0000 jlkp bhga cfhf becd]
>    ```
> 
> 3. `MaxVectorSize = 64, byte_vector_size = MaxVectorSize / 4`:
>    - Can load 16 indices per vector register
>    - So can ...

Changes requested by syan (Committer).

test/hotspot/jtreg/compiler/vectorapi/VectorGatherSubwordTest.java line 39:

> 37:  * @modules jdk.incubator.vector
> 38:  *
> 39:  * @run driver compiler.vectorapi.VectorGatherSubwordTest

Should we use `@run main` instead of `@run driver`

-------------

PR Review: https://git.openjdk.org/jdk/pull/24679#pullrequestreview-2780137136
PR Review Comment: https://git.openjdk.org/jdk/pull/24679#discussion_r2051625676

From syan at openjdk.org  Sun Apr 20 03:44:40 2025
From: syan at openjdk.org (SendaoYan)
Date: Sun, 20 Apr 2025 03:44:40 GMT
Subject: RFR: 8354898: jdk/internal/loader/NativeLibraries/Main.java fails
 on static JDK
In-Reply-To: 
References: 
Message-ID: 

On Wed, 16 Apr 2025 23:41:40 GMT, Jiangli Zhou  wrote:

> Please review this simple test change that skips the test case loading using JDK `libzip.so` on static JDK in test/jdk/jdk/internal/loader/NativeLibraries/Main.java. AFAICT, the test case using `NativeLibrariesTest.LIB_NAME` (`libnativeLibrariesTest.so`) can provide coverage on static JDK.
> 
> Thanks

test/jdk/jdk/internal/loader/NativeLibraries/Main.java line 61:

> 59:         // load zip library from JDK
> 60:         if (!Platform.isStatic()) {
> 61:             test.load(System.mapLibraryName("zip"), true /* succeed */);

Hi, the other tests which also call `NativeLibrariesTest.load(String, boolean)`, does the other tests also need this check `!Platform.isStatic()`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24704#discussion_r2051627101

From joehw at openjdk.org  Sun Apr 20 05:36:40 2025
From: joehw at openjdk.org (Joe Wang)
Date: Sun, 20 Apr 2025 05:36:40 GMT
Subject: RFR: 8354774: DocumentBuilderFactory getAttribute throws NPE [v2]
In-Reply-To: 
References: 
 <0bAwDMoPMDTI66jUMmkU_Fo7oEW4XYIGbkYnJz3jK74=.991ad888-be65-422e-a2fd-b702fff5c437@github.com>
 
Message-ID: 

On Sun, 20 Apr 2025 03:05:20 GMT, SendaoYan  wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove unused variable pName; remove unused imports
>
> test/jaxp/javax/xml/jaxp/unittest/common/PropertiesTest.java line 47:
> 
>> 45:  * @summary Verifies JAXP API Properties as specified in the java.xml module.
>> 46:  * @library /javax/xml/jaxp/libs /javax/xml/jaxp/unittest /test/lib
>> 47:  * @run junit/othervm common.PropertiesTest
> 
> `/othervm` seems do not needed

It's necessary as the test may set System Properties.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24732#discussion_r2051639843

From jzaugg at openjdk.org  Sun Apr 20 13:01:30 2025
From: jzaugg at openjdk.org (Jason Zaugg)
Date: Sun, 20 Apr 2025 13:01:30 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance [v3]
In-Reply-To: 
References: 
Message-ID: 

> 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance

Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright and remove part of comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24176/files
  - new: https://git.openjdk.org/jdk/pull/24176/files/e0d40f4d..e1334955

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24176&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24176&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24176.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24176/head:pull/24176

PR: https://git.openjdk.org/jdk/pull/24176

From jzaugg at openjdk.org  Sun Apr 20 13:01:30 2025
From: jzaugg at openjdk.org (Jason Zaugg)
Date: Sun, 20 Apr 2025 13:01:30 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance [v2]
In-Reply-To: <4YJv_Epumc0H6kV6HXamzgbBGQ4rqsgLF6_x3Zgs1OU=.4ae39a90-887e-4c6b-a95c-d29727848336@github.com>
References: 
 <8UqLlWwRDd27THNn3oXl2n3LNc6UODiKoPYJa7p3S_0=.c38e4afe-2823-4ffe-9557-01295137930f@github.com>
 
 <4YJv_Epumc0H6kV6HXamzgbBGQ4rqsgLF6_x3Zgs1OU=.4ae39a90-887e-4c6b-a95c-d29727848336@github.com>
Message-ID: 

On Tue, 8 Apr 2025 09:22:32 GMT, Jaikiran Pai  wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 581:
>> 
>>> 579:                 // Less common case is possible if the file manager was not initialized in JavacTask,
>>> 580:                 // or if non "*.jar" files are on the classpath. At the time of writing, both `javac -cp a.zip`
>>> 581:                 // and `javac -cp x.JAR` file would hit this branch which may warrant investigation.
>> 
>> Hello Jason, do we need that second sentence to be added as a code comment? I feel it creates confusion on what's expected to be done. Perhaps just add that first sentence and remove the second?
>
> Could you also update the copyright year on this file from 2024 to 2025?

All done now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24176#discussion_r2051718910

From duke at openjdk.org  Sun Apr 20 16:07:56 2025
From: duke at openjdk.org (fabioromano1)
Date: Sun, 20 Apr 2025 16:07:56 GMT
Subject: RFR: 8077587: BigInteger Roots [v19]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

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/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/524f195e..21fbf278

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=17-18

  Stats: 8 lines in 1 file changed: 0 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From liach at openjdk.org  Mon Apr 21 01:01:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Apr 2025 01:01:53 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance [v3]
In-Reply-To: 
References: 
 
Message-ID: <9QeFd0gd2TEGV-GqjiSibXZeuIjupqm7hZ2KCWqAooQ=.8a3168fc-f040-4900-b9f4-343aed6073f6@github.com>

On Sun, 20 Apr 2025 13:01:30 GMT, Jason Zaugg  wrote:

>> 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance
>
> Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright and remove part of comment

Marked as reviewed by liach (Reviewer).

So the bot blocks this PR because "body is empty" - you can just paste something from the JBS issue to fix that, or provide your own short description.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24176#pullrequestreview-2780384310
PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2817434077

From swen at openjdk.org  Mon Apr 21 01:25:48 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 21 Apr 2025 01:25:48 GMT
Subject: RFR: 8077587: BigInteger Roots [v19]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 20 Apr 2025 16:07:56 GMT, fabioromano1  wrote:

>> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
>> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code simplification

It is recommended not to format or rename unrelated code in this PR. You should make minimal changes to achieve the purpose of this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2817450601

From liach at openjdk.org  Mon Apr 21 01:36:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Apr 2025 01:36:50 GMT
Subject: RFR: 8077587: BigInteger Roots [v18]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 19 Apr 2025 19:23:26 GMT, fabioromano1  wrote:

>> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
>> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)
>
> fabioromano1 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 21 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into BigInteger-nth-root
>  - Format code
>  - Format code
>  - An optimization
>  - An optimization
>  - Extend use cases of MutableBigInteger.valueOf(double)
>  - BigIntegers nth root's initial estimate optimization
>  - An optimization
>  - Memory usage optimization
>  - Correct left shift if shift is zero
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/966f9022...524f195e

src/java.base/share/classes/java/math/BigInteger.java line 2669:

> 2667:             // Perform exponentiation using repeated squaring trick
> 2668:             for (int expLen = Integer.SIZE - expZeros; expLen > 0; expLen--) {
> 2669:                 answer = answer.multiply(answer);

Is `answer.multiply(answer)` faster than `answer.square()`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2051636729

From jiangli at openjdk.org  Mon Apr 21 03:08:08 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 21 Apr 2025 03:08:08 GMT
Subject: RFR: 8354898: jdk/internal/loader/NativeLibraries/Main.java fails
 on static JDK
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 20 Apr 2025 03:42:32 GMT, SendaoYan  wrote:

>> Please review this simple test change that skips the test case loading using JDK `libzip.so` on static JDK in test/jdk/jdk/internal/loader/NativeLibraries/Main.java. AFAICT, the test case using `NativeLibrariesTest.LIB_NAME` (`libnativeLibrariesTest.so`) can provide coverage on static JDK.
>> 
>> Thanks
>
> test/jdk/jdk/internal/loader/NativeLibraries/Main.java line 61:
> 
>> 59:         // load zip library from JDK
>> 60:         if (!Platform.isStatic()) {
>> 61:             test.load(System.mapLibraryName("zip"), true /* succeed */);
> 
> Hi, the other tests which also call `NativeLibrariesTest.load(String, boolean)`, does the other tests also need this check `!Platform.isStatic()`

@sendaoYan, `NativeLibrariesTest` is only used by [test/jdk/jdk/internal/loader/NativeLibraries/Main.java](https://github.com/openjdk/jdk/pull/24704/files/225d43fd59f190dfcff50f31e2cab6db2a4dd018#diff-9be6f1f8ea6281e6f1cdda8bf7e717174ea7d12af541c7772facd6af9e37f06b).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24704#discussion_r2051901966

From jpai at openjdk.org  Mon Apr 21 05:13:41 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 21 Apr 2025 05:13:41 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine [v2]
In-Reply-To: 
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
 
Message-ID: <3neEYF1L5DoBDB4uqtJGNCg5R41dkNLoCpoKhI5_6oc=.21b5b1b4-aff4-4492-82d5-9b3be9107ef1@github.com>

On Thu, 17 Apr 2025 20:51:10 GMT, Chen Liang  wrote:

>> When jdeps was migrated from old classfile to ClassFile API, the parsing semantic changed - error checks are now made lazily, and nested crashes from malformed signature or other problems is now latent, after a `ClassModel` instance is available. (The old error check existed only for constructing a `ClassModel`)
>> 
>> To address this issue, I have updated the way of iterating class files to be handler/consumer based like in the ClassFile API. This has the advantage that when one invocation of the handler fails of a `ClassFileError`, other invocations for other class files can proceed, and the exception handler has sufficient information to report a useful message indicating the source of error.
>> 
>> For the particular example of examining a proguard processed `dummy-scala.jar`, here is the new output of `jdeps dummy-scala.jar`:
>> 
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 59, expected an identifier: Lscala/collection/immutable/TreeMap$TreeMapBuilder.;: scala/collection/immutable/TreeMap$TreeMapBuilder.class (dummy-scala.jar)
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 49, expected an identifier: Lscala/collection/parallel/mutable/ParArray.;: scala/collection/parallel/mutable/ParArray.class (dummy-scala.jar)
>> 
>> 
>> Now, jdeps shows the bad class files. Inspection into the files reveal that proguard incorrectly deleted the simple class names with trailing `$`, for example, the original signature of the broken ParArray was `Lscala/collection/parallel/mutable/ParArray.ParArrayIterator$;`, so the `ParArrayIterator$` part was incorrectly dropped by proguard.
>> 
>> Testing: langtools/tools/jdeps.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks

Hello Chen,

> Unfortunately, I don't think there is a convenient way to make a jar with jtreg tests.

There are several tests in the JDK repo which create a JAR file of their choice within the test code and then run some tests against the JAR file. In fact, existing tests for `jdeps` tool already has similar tests. For example, there's a `JdepsUtil` test library which has a `createJar(...)` utility method which some of these tests use. This new test can use that utility if necessary.

In addition to testing this change against a JAR file, I think the test could also include running `jdeps` against a directory which contains more than one class file with one of the class file exhibiting the reported issue. That will then be able to reproduce the issue and verify the fix when running `jdeps` against a directory.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24604#issuecomment-2817647358

From liach at openjdk.org  Mon Apr 21 05:33:45 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Apr 2025 05:33:45 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine [v2]
In-Reply-To: 
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
 
Message-ID: <6zKD2kAv2tNb0BKUaoIWoLwhFC9uR5Qn5OmH9tCzDuY=.2ecbcd4c-5017-4ea6-b99c-57a329c97846@github.com>

On Thu, 17 Apr 2025 20:51:10 GMT, Chen Liang  wrote:

>> When jdeps was migrated from old classfile to ClassFile API, the parsing semantic changed - error checks are now made lazily, and nested crashes from malformed signature or other problems is now latent, after a `ClassModel` instance is available. (The old error check existed only for constructing a `ClassModel`)
>> 
>> To address this issue, I have updated the way of iterating class files to be handler/consumer based like in the ClassFile API. This has the advantage that when one invocation of the handler fails of a `ClassFileError`, other invocations for other class files can proceed, and the exception handler has sufficient information to report a useful message indicating the source of error.
>> 
>> For the particular example of examining a proguard processed `dummy-scala.jar`, here is the new output of `jdeps dummy-scala.jar`:
>> 
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 59, expected an identifier: Lscala/collection/immutable/TreeMap$TreeMapBuilder.;: scala/collection/immutable/TreeMap$TreeMapBuilder.class (dummy-scala.jar)
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 49, expected an identifier: Lscala/collection/parallel/mutable/ParArray.;: scala/collection/parallel/mutable/ParArray.class (dummy-scala.jar)
>> 
>> 
>> Now, jdeps shows the bad class files. Inspection into the files reveal that proguard incorrectly deleted the simple class names with trailing `$`, for example, the original signature of the broken ParArray was `Lscala/collection/parallel/mutable/ParArray.ParArrayIterator$;`, so the `ParArrayIterator$` part was incorrectly dropped by proguard.
>> 
>> Testing: langtools/tools/jdeps.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks

Thanks, I saw there is `JarUtils`, which IMO can have a new utility `createJar(Path jarfile, Map entries)` that can directly accept the output of `InMemoryJavaCompiler.compile`. Expressing small classes with text blocks instead of standalone files can reduce redundancy from license headers. I will work on this when I am free later; going to bed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24604#issuecomment-2817670026

From ccheung at openjdk.org  Mon Apr 21 06:20:46 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 21 Apr 2025 06:20:46 GMT
Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking [v3]
In-Reply-To: 
References: 
Message-ID: 

> This RFE allows --add-opens to be specified for AOT cache creation. AOT cache can be used during production run with --add-opens option as long as the same set of options is used during assembly phase.
> 
> Passed tiers 1 - 4 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  @iklam comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24695/files
  - new: https://git.openjdk.org/jdk/pull/24695/files/658a895b..2ae685f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24695&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24695&range=01-02

  Stats: 34 lines in 2 files changed: 11 ins; 0 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/24695.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24695/head:pull/24695

PR: https://git.openjdk.org/jdk/pull/24695

From ccheung at openjdk.org  Mon Apr 21 06:23:40 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 21 Apr 2025 06:23:40 GMT
Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking
In-Reply-To: 
References: 
 
 
 
Message-ID: <9H_ma7ygGh42q9vBWVI8rcNGZI-R6cr-MorerpAPMkI=.9cb484a0-aac2-49b6-8f78-1df57f312115@github.com>

On Fri, 18 Apr 2025 01:41:36 GMT, Ioi Lam  wrote:

> 
> AddopensOption.java only checks if the --add-opens is accepted. It doesn't check if the option has any effect. I think it's better to run `TEST_MODULE1` to make sure that `setAccessible` can be called without throwing an exception. That will verify that the option has achieved the intended effect.

I've modified the AppOpens.java test to include `--add-opens` during dump time.
Also needed to change ModuleBootStrap.java slightly for the test to run correctly. The change is to add the call to `addExtraExportsAndOpens(bootLayer)` in the case where the bootLayer is obtained from CDS archive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24695#issuecomment-2817735297

From duke at openjdk.org  Mon Apr 21 08:06:52 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 21 Apr 2025 08:06:52 GMT
Subject: RFR: 8077587: BigInteger Roots [v18]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sun, 20 Apr 2025 05:12:19 GMT, Chen Liang  wrote:

>> fabioromano1 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 21 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into BigInteger-nth-root
>>  - Format code
>>  - Format code
>>  - An optimization
>>  - An optimization
>>  - Extend use cases of MutableBigInteger.valueOf(double)
>>  - BigIntegers nth root's initial estimate optimization
>>  - An optimization
>>  - Memory usage optimization
>>  - Correct left shift if shift is zero
>>  - ... and 11 more: https://git.openjdk.org/jdk/compare/d7448f7e...524f195e
>
> src/java.base/share/classes/java/math/BigInteger.java line 2669:
> 
>> 2667:             // Perform exponentiation using repeated squaring trick
>> 2668:             for (int expLen = Integer.SIZE - expZeros; expLen > 0; expLen--) {
>> 2669:                 answer = answer.multiply(answer);
> 
> Is `answer.multiply(answer)` faster than `answer.square()`?

It should be, because `multiply(BigInteger)` checks the size of the argument in order to call `square()` when it is more convenient.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2052102817

From aturbanov at openjdk.org  Mon Apr 21 08:13:43 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 21 Apr 2025 08:13:43 GMT
Subject: RFR: 8354774: DocumentBuilderFactory getAttribute throws NPE [v2]
In-Reply-To: <0bAwDMoPMDTI66jUMmkU_Fo7oEW4XYIGbkYnJz3jK74=.991ad888-be65-422e-a2fd-b702fff5c437@github.com>
References: 
 <0bAwDMoPMDTI66jUMmkU_Fo7oEW4XYIGbkYnJz3jK74=.991ad888-be65-422e-a2fd-b702fff5c437@github.com>
Message-ID: 

On Fri, 18 Apr 2025 21:26:23 GMT, Joe Wang  wrote:

>> Fix a NPE on calling DocumentBuilderFactory::getAttribute, refer to the bug report.
>> 
>> Also in this patch: consolidates get and set properties to use the same Util methods to reduce potential errors when code changes.
>> 
>> Test:
>>     Tier1 - 3 passed
>>     JCK test passed
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused variable pName; remove unused imports

src/java.xml/share/classes/jdk/xml/internal/JdkXmlUtils.java line 133:

> 131:             String property) {
> 132:         String value = null;
> 133:         if  (xsm != null && (value = xsm.getLimitAsString(property)) != null) {

Suggestion:

        if (xsm != null && (value = xsm.getLimitAsString(property)) != null) {

test/jaxp/javax/xml/jaxp/unittest/common/PropertiesTest.java line 128:

> 126:             case DOM:
> 127:                 DocumentBuilderFactory dbf = DocumentBuilderFactory.newDefaultInstance();
> 128:                 if (apiValue != null)  dbf.setAttribute(apiProperty, apiValue);

Suggestion:

                if (apiValue != null) dbf.setAttribute(apiProperty, apiValue);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24732#discussion_r2052113086
PR Review Comment: https://git.openjdk.org/jdk/pull/24732#discussion_r2052112697

From aturbanov at openjdk.org  Mon Apr 21 08:20:44 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 21 Apr 2025 08:20:44 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v6]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
Message-ID: 

On Fri, 18 Apr 2025 20:10:32 GMT, Brian Burkhalter  wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8354724: Remove unused import

test/jdk/java/io/BufferedReader/ReadAll.java line 70:

> 68:         int size = rnd.nextInt(2, 16386);
> 69: 
> 70:         try (FileChannel fc = FileChannel.open(path, CREATE, WRITE);) {

Suggestion:

        try (FileChannel fc = FileChannel.open(path, CREATE, WRITE)) {

test/jdk/java/io/BufferedReader/ReadAll.java line 104:

> 102:         List lines;
> 103:         try (FileReader fr = new FileReader(file);
> 104:              BufferedReader br = new BufferedReader(fr);) {

Suggestion:

             BufferedReader br = new BufferedReader(fr)) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2052118847
PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2052119014

From aph at openjdk.org  Mon Apr 21 08:38:41 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 21 Apr 2025 08:38:41 GMT
Subject: RFR: 8077587: BigInteger Roots [v19]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 20 Apr 2025 16:07:56 GMT, fabioromano1  wrote:

>> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
>> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code simplification

src/java.base/share/classes/java/math/MutableBigInteger.java line 2002:

> 2000:             // Don't use conditional-or to ensure to do both divisions
> 2001:             if (rToN.divideOneWord(n, q1) != 0
> 2002:                     | !q1.divide(new MutableBigInteger(rToN1.mag), delta).isZero())

Suggestion:

            // Don't use conditional-or to ensure to do both divisions [because ...]
            if ((rToN.divideOneWord(n, q1) != 0)
                    | (!q1.divide(new MutableBigInteger(rToN1.mag), delta).isZero()))

... add parens for clarity.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2052135457

From aph at openjdk.org  Mon Apr 21 10:08:08 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 21 Apr 2025 10:08:08 GMT
Subject: RFR: 8077587: BigInteger Roots [v19]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 20 Apr 2025 16:07:56 GMT, fabioromano1  wrote:

>> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
>> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code simplification

src/java.base/share/classes/java/math/MutableBigInteger.java line 1924:

> 1922:      * @implNote The implementation is based on the material in Henry S. Warren,
> 1923:      * Jr., Hacker's Delight (2nd ed.) (Addison Wesley, 2013), 279-282.
> 1924:      *

* @implNote The implementation is based on the material in Henry S. Warren,
     * Jr., Hacker's Delight (2nd ed.) (Addison Wesley, 2013), 279-282.
     *

I'm looking at this reference, and I only see integer square root here. But this is n >= 3.

I do see an explanation at [nth root](https://en.wikipedia.org/wiki/Nth_root#Computing_principal_roots)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2052217018

From aph at openjdk.org  Mon Apr 21 10:16:46 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 21 Apr 2025 10:16:46 GMT
Subject: RFR: 8077587: BigInteger Roots [v19]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 20 Apr 2025 16:07:56 GMT, fabioromano1  wrote:

>> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
>> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code simplification

> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

That's very nice. It would be even nicer if this was a permalink into the JDK repo, and a reference in the source code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2818103511

From swen at openjdk.org  Mon Apr 21 10:18:35 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 21 Apr 2025 10:18:35 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 UTF16::compress & Unsafe::copyMemory
Message-ID: 

In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string.

For these scenarios, we can use the intrinsic method StringUTF16.compress and Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed.

-------------

Commit messages:
 - copyright
 - Using StringUTF16.compress to speed up LATIN1 StringBuilder append(char[])
 - Using Unsafe.copyMemory to speed up UTF16 StringBuilder append(char[])
 - add append(char[]) benchmark

Changes: https://git.openjdk.org/jdk/pull/24773/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24773&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355177
  Stats: 46 lines in 3 files changed: 40 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24773.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24773/head:pull/24773

PR: https://git.openjdk.org/jdk/pull/24773

From swen at openjdk.org  Mon Apr 21 10:18:35 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 21 Apr 2025 10:18:35 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 UTF16::compress & Unsafe::copyMemory
In-Reply-To: 
References: 
Message-ID: 

On Mon, 21 Apr 2025 07:00:36 GMT, Shaojin Wen  wrote:

> In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string.
> 
> For these scenarios, we can use the intrinsic method StringUTF16.compress and Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed.

Below are the performance numbers on a MacBookPro M1 Max, showing a 112% speed increase when coder = LATIN1 and a 44.19% speed increase when coder = UTF16.

# shell

git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

# basline
git clone ee356d3af177877e2702db08a3b55d170a7e454c
make test TEST="micro:java.lang.StringBuilders.appendWithCharArray"

# current
git clone cd5137097b4a7be370cf60df9aa5000203ea99c0
make test TEST="micro:java.lang.StringBuilders.appendWithCharArray"


# Performance Numbrers

-Benchmark                                 Mode  Cnt   Score   Error  Units (baseline cd5137097b4)
-StringBuilders.appendWithCharArrayLatin1  avgt   15  33.039 ? 0.059  ns/op
-StringBuilders.appendWithCharArrayUTF16   avgt   15  19.977 ? 0.054  ns/op

+Benchmark                                 Mode  Cnt   Score   Error  Units (current ee356d3af17)
+StringBuilders.appendWithCharArrayLatin1  avgt   15  15.533 ? 0.039  ns/op +112.70%
+StringBuilders.appendWithCharArrayUTF16   avgt   15  13.868 ? 0.053  ns/op +44.19%

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24773#issuecomment-2817873466

From duke at openjdk.org  Mon Apr 21 11:45:46 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 21 Apr 2025 11:45:46 GMT
Subject: RFR: 8077587: BigInteger Roots [v19]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 21 Apr 2025 10:05:21 GMT, Andrew Haley  wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Code simplification
>
> src/java.base/share/classes/java/math/MutableBigInteger.java line 1924:
> 
>> 1922:      * @implNote The implementation is based on the material in Henry S. Warren,
>> 1923:      * Jr., Hacker's Delight (2nd ed.) (Addison Wesley, 2013), 279-282.
>> 1924:      *
> 
> * @implNote The implementation is based on the material in Henry S. Warren,
>      * Jr., Hacker's Delight (2nd ed.) (Addison Wesley, 2013), 279-282.
>      *
> 
> I'm looking at this reference, and I only see integer square root here. But this is n >= 3.
> 
> I do see an explanation at [nth root](https://en.wikipedia.org/wiki/Nth_root#Computing_principal_roots)

I have put a proof of the recurrence in the description of the PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2052298673

From duke at openjdk.org  Mon Apr 21 11:49:45 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 21 Apr 2025 11:49:45 GMT
Subject: RFR: 8077587: BigInteger Roots [v19]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 21 Apr 2025 10:14:05 GMT, Andrew Haley  wrote:

> That's very nice. It would be even nicer if this was a permalink into the JDK repo, and a reference in the source code.

@theRealAph Ok. It would be useful to have a link to an explanation on how this can be done, if there is one. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2818254412

From duke at openjdk.org  Mon Apr 21 13:10:43 2025
From: duke at openjdk.org (Markus KARG)
Date: Mon, 21 Apr 2025 13:10:43 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sun, 23 Mar 2025 10:33:42 GMT, Markus KARG  wrote:

>> src/java.base/share/classes/java/nio/X-Buffer.java.template line 2356:
>> 
>>> 2354: #end[streamableType]
>>> 2355: 
>>> 2356: #if[char]
>> 
>> Can we merge this with `// -- Other char stuff --` on line 1895?
>> 
>> On a side note, we can optimize a lot of Appendable operations that transfer from CharSequence on CharBuffer; don't know if you wish to have it in this RFE or another.
>
> Fixed in a3c2add9c16e4c7331c5a7c2848f27b6c0330a17.
> 
> Let's finish this PR first. After that I would be happy to author another PR with all the optimizations you tell me. ?

> On a side note, we can optimize a lot of Appendable operations that transfer from CharSequence on CharBuffer; don't know if you wish to have it in this RFE or another.

@liach FYI, I have just startet work on an experimental impementation for `Appendable`s utilizing `CharSequence.getChars`. So far, it really looks rather primising, as it gets rid of lots of potental copies in favor of absolute bulk get. My target is to turn it into a separate RFE eventually, once 8343110 is finally merged. ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2052366020

From duke at openjdk.org  Mon Apr 21 14:31:36 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 21 Apr 2025 14:31:36 GMT
Subject: RFR: 8077587: BigInteger Roots [v20]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Added reference for proof of convergence in the comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/21fbf278..e11b32f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=18-19

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From liach at openjdk.org  Mon Apr 21 14:59:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Apr 2025 14:59:59 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine [v2]
In-Reply-To: <3neEYF1L5DoBDB4uqtJGNCg5R41dkNLoCpoKhI5_6oc=.21b5b1b4-aff4-4492-82d5-9b3be9107ef1@github.com>
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
 
 <3neEYF1L5DoBDB4uqtJGNCg5R41dkNLoCpoKhI5_6oc=.21b5b1b4-aff4-4492-82d5-9b3be9107ef1@github.com>
Message-ID: 

On Mon, 21 Apr 2025 05:10:48 GMT, Jaikiran Pai  wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks
>
> Hello Chen,
> 
>> Unfortunately, I don't think there is a convenient way to make a jar with jtreg tests.
> 
> There are several tests in the JDK repo which create a JAR file of their choice within the test code and then run some tests against the JAR file. In fact, existing tests for `jdeps` tool already has similar tests. For example, there's a `JdepsUtil` test library which has a `createJar(...)` utility method which some of these tests use. This new test can use that utility if necessary.
> 
> In addition to testing this change against a JAR file, I think the test could also include running `jdeps` against a directory which contains more than one class file with one of the class file exhibiting the reported issue. That will then be able to reproduce the issue and verify the fix when running `jdeps` against a directory.

@jaikiran Done. Please review again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24604#issuecomment-2818674103

From liach at openjdk.org  Mon Apr 21 14:59:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Apr 2025 14:59:59 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine [v3]
In-Reply-To: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
Message-ID: 

> When jdeps was migrated from old classfile to ClassFile API, the parsing semantic changed - error checks are now made lazily, and nested crashes from malformed signature or other problems is now latent, after a `ClassModel` instance is available. (The old error check existed only for constructing a `ClassModel`)
> 
> To address this issue, I have updated the way of iterating class files to be handler/consumer based like in the ClassFile API. This has the advantage that when one invocation of the handler fails of a `ClassFileError`, other invocations for other class files can proceed, and the exception handler has sufficient information to report a useful message indicating the source of error.
> 
> For the particular example of examining a proguard processed `dummy-scala.jar`, here is the new output of `jdeps dummy-scala.jar`:
> 
> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 59, expected an identifier: Lscala/collection/immutable/TreeMap$TreeMapBuilder.;: scala/collection/immutable/TreeMap$TreeMapBuilder.class (dummy-scala.jar)
> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 49, expected an identifier: Lscala/collection/parallel/mutable/ParArray.;: scala/collection/parallel/mutable/ParArray.class (dummy-scala.jar)
> 
> 
> Now, jdeps shows the bad class files. Inspection into the files reveal that proguard incorrectly deleted the simple class names with trailing `$`, for example, the original signature of the broken ParArray was `Lscala/collection/parallel/mutable/ParArray.ParArrayIterator$;`, so the `ParArrayIterator$` part was incorrectly dropped by proguard.
> 
> Testing: langtools/tools/jdeps.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Add a test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24604/files
  - new: https://git.openjdk.org/jdk/pull/24604/files/7d2d5d0c..f61e9201

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24604&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24604&range=01-02

  Stats: 169 lines in 5 files changed: 165 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24604.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24604/head:pull/24604

PR: https://git.openjdk.org/jdk/pull/24604

From duke at openjdk.org  Mon Apr 21 15:04:37 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 21 Apr 2025 15:04:37 GMT
Subject: RFR: 8077587: BigInteger Roots [v21]
In-Reply-To: 
References: 
Message-ID: <6OVUBPouKyMXRvMCr2pzZS5D4VTokj_2YmzGn6Ri938=.26716ec2-e778-4f5c-9a3c-d31199e4c2b2@github.com>

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'BigInteger-nth-root' of https://github.com/fabioromano1/jdk into BigInteger-nth-root
 - Revert format code changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/e11b32f5..8de6b825

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=19-20

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From liach at openjdk.org  Mon Apr 21 15:22:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Apr 2025 15:22:41 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 UTF16::compress & Unsafe::copyMemory
In-Reply-To: 
References: 
Message-ID: <2zlSFcT1XiOm_I2AsEmRYsi3hPVec_7BEIhxFI5wyro=.5f31ddfe-29b4-4794-906f-8865d7e57121@github.com>

On Mon, 21 Apr 2025 07:00:36 GMT, Shaojin Wen  wrote:

> In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string.
> 
> For these scenarios, we can use the intrinsic method StringUTF16.compress and Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed.

This might be helpful combined with #21730.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24773#issuecomment-2818748083

From liach at openjdk.org  Mon Apr 21 15:30:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Apr 2025 15:30:46 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 UTF16::compress & Unsafe::copyMemory
In-Reply-To: 
References: 
Message-ID: 

On Mon, 21 Apr 2025 07:00:36 GMT, Shaojin Wen  wrote:

> In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string.
> 
> For these scenarios, we can use the intrinsic method StringUTF16.compress and Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1773:

> 1771:             int compressed = StringUTF16.compress(s, off, val, count, end - off);
> 1772:             count += compressed;
> 1773:             off += compressed;

Should we update `this.count` eagerly after compression?

src/java.base/share/classes/java/lang/StringUTF16.java line 1317:

> 1315:     }
> 1316: 
> 1317:     private static void putChars(byte[] val, int index, char[] str, int off, int end) {

I recommend renaming this to `putCharsUnchecked` to indicate this has no bound checks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2052591347
PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2052597288

From jpai at openjdk.org  Mon Apr 21 15:43:46 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 21 Apr 2025 15:43:46 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine [v3]
In-Reply-To: 
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
 
Message-ID: 

On Mon, 21 Apr 2025 14:59:59 GMT, Chen Liang  wrote:

>> When jdeps was migrated from old classfile to ClassFile API, the parsing semantic changed - error checks are now made lazily, and nested crashes from malformed signature or other problems is now latent, after a `ClassModel` instance is available. (The old error check existed only for constructing a `ClassModel`)
>> 
>> To address this issue, I have updated the way of iterating class files to be handler/consumer based like in the ClassFile API. This has the advantage that when one invocation of the handler fails of a `ClassFileError`, other invocations for other class files can proceed, and the exception handler has sufficient information to report a useful message indicating the source of error.
>> 
>> For the particular example of examining a proguard processed `dummy-scala.jar`, here is the new output of `jdeps dummy-scala.jar`:
>> 
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 59, expected an identifier: Lscala/collection/immutable/TreeMap$TreeMapBuilder.;: scala/collection/immutable/TreeMap$TreeMapBuilder.class (dummy-scala.jar)
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 49, expected an identifier: Lscala/collection/parallel/mutable/ParArray.;: scala/collection/parallel/mutable/ParArray.class (dummy-scala.jar)
>> 
>> 
>> Now, jdeps shows the bad class files. Inspection into the files reveal that proguard incorrectly deleted the simple class names with trailing `$`, for example, the original signature of the broken ParArray was `Lscala/collection/parallel/mutable/ParArray.ParArrayIterator$;`, so the `ParArrayIterator$` part was incorrectly dropped by proguard.
>> 
>> Testing: langtools/tools/jdeps.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a test

Thank you Chen for adding the test. The test looks good to me. I verified locally that it does indeed reproduce the original issue without the fix.

I've just one final request - since the `DirectoryIterator` has been updated in this PR, I think it would be good to include in your test, a `jdeps` invocation against a directory just like against you do it for the JAR file.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24604#pullrequestreview-2781628423

From jpai at openjdk.org  Mon Apr 21 15:46:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 21 Apr 2025 15:46:48 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine [v3]
In-Reply-To: 
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
 
Message-ID: 

On Mon, 21 Apr 2025 14:59:59 GMT, Chen Liang  wrote:

>> When jdeps was migrated from old classfile to ClassFile API, the parsing semantic changed - error checks are now made lazily, and nested crashes from malformed signature or other problems is now latent, after a `ClassModel` instance is available. (The old error check existed only for constructing a `ClassModel`)
>> 
>> To address this issue, I have updated the way of iterating class files to be handler/consumer based like in the ClassFile API. This has the advantage that when one invocation of the handler fails of a `ClassFileError`, other invocations for other class files can proceed, and the exception handler has sufficient information to report a useful message indicating the source of error.
>> 
>> For the particular example of examining a proguard processed `dummy-scala.jar`, here is the new output of `jdeps dummy-scala.jar`:
>> 
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 59, expected an identifier: Lscala/collection/immutable/TreeMap$TreeMapBuilder.;: scala/collection/immutable/TreeMap$TreeMapBuilder.class (dummy-scala.jar)
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 49, expected an identifier: Lscala/collection/parallel/mutable/ParArray.;: scala/collection/parallel/mutable/ParArray.class (dummy-scala.jar)
>> 
>> 
>> Now, jdeps shows the bad class files. Inspection into the files reveal that proguard incorrectly deleted the simple class names with trailing `$`, for example, the original signature of the broken ParArray was `Lscala/collection/parallel/mutable/ParArray.ParArrayIterator$;`, so the `ParArrayIterator$` part was incorrectly dropped by proguard.
>> 
>> Testing: langtools/tools/jdeps.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a test

test/langtools/tools/jdeps/MalformedClassesTest.java line 28:

> 26:  * @bug 8341608
> 27:  * @summary Tests for jdeps tool with jar files with malformed classes
> 28:  * @library lib /test/lib jdk.jdeps

I am not too familiar with the `jdk.jdeps` style usage of `@library` here. Does the test still function without that `jdk.jdeps` entry? I briefly looked up the documentation of `@library` https://openjdk.org/jtreg/tag-spec.html#tags and it isn't clear to me what jtreg does with such a declaration.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24604#discussion_r2052629495

From swen at openjdk.org  Mon Apr 21 15:51:58 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 21 Apr 2025 15:51:58 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 UTF16::compress & Unsafe::copyMemory [v2]
In-Reply-To: 
References: 
Message-ID: 

> In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string.
> 
> For these scenarios, we can use the intrinsic method StringUTF16.compress and Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  putCharsUnchecked

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24773/files
  - new: https://git.openjdk.org/jdk/pull/24773/files/ee356d3a..ec6482b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24773&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24773&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24773.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24773/head:pull/24773

PR: https://git.openjdk.org/jdk/pull/24773

From swen at openjdk.org  Mon Apr 21 15:51:58 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 21 Apr 2025 15:51:58 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 UTF16::compress & Unsafe::copyMemory [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 21 Apr 2025 15:25:34 GMT, Chen Liang  wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   putCharsUnchecked
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1773:
> 
>> 1771:             int compressed = StringUTF16.compress(s, off, val, count, end - off);
>> 1772:             count += compressed;
>> 1773:             off += compressed;
> 
> Should we update `this.count` eagerly after compression?

In the StringLatin1.canEncode(c) branch of the original code, this.count is not updated either, and the behavior is the same as before.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2052637495

From liach at openjdk.org  Mon Apr 21 16:06:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Apr 2025 16:06:26 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine [v3]
In-Reply-To: 
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
 
 
Message-ID: 

On Mon, 21 Apr 2025 15:44:20 GMT, Jaikiran Pai  wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a test
>
> test/langtools/tools/jdeps/MalformedClassesTest.java line 28:
> 
>> 26:  * @bug 8341608
>> 27:  * @summary Tests for jdeps tool with jar files with malformed classes
>> 28:  * @library lib /test/lib jdk.jdeps
> 
> I am not too familiar with the `jdk.jdeps` style usage of `@library` here. Does the test still function without that `jdk.jdeps` entry? I briefly looked up the documentation of `@library` https://openjdk.org/jtreg/tag-spec.html#tags and it isn't clear to me what jtreg does with such a declaration.

Turns out this is not necessary when I have `@build jdk.jdeps/com.sun.tools.jdeps.*`. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24604#discussion_r2052655127

From liach at openjdk.org  Mon Apr 21 16:06:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Apr 2025 16:06:25 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine [v4]
In-Reply-To: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
Message-ID: 

> When jdeps was migrated from old classfile to ClassFile API, the parsing semantic changed - error checks are now made lazily, and nested crashes from malformed signature or other problems is now latent, after a `ClassModel` instance is available. (The old error check existed only for constructing a `ClassModel`)
> 
> To address this issue, I have updated the way of iterating class files to be handler/consumer based like in the ClassFile API. This has the advantage that when one invocation of the handler fails of a `ClassFileError`, other invocations for other class files can proceed, and the exception handler has sufficient information to report a useful message indicating the source of error.
> 
> For the particular example of examining a proguard processed `dummy-scala.jar`, here is the new output of `jdeps dummy-scala.jar`:
> 
> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 59, expected an identifier: Lscala/collection/immutable/TreeMap$TreeMapBuilder.;: scala/collection/immutable/TreeMap$TreeMapBuilder.class (dummy-scala.jar)
> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 49, expected an identifier: Lscala/collection/parallel/mutable/ParArray.;: scala/collection/parallel/mutable/ParArray.class (dummy-scala.jar)
> 
> 
> Now, jdeps shows the bad class files. Inspection into the files reveal that proguard incorrectly deleted the simple class names with trailing `$`, for example, the original signature of the broken ParArray was `Lscala/collection/parallel/mutable/ParArray.ParArrayIterator$;`, so the `ParArrayIterator$` part was incorrectly dropped by proguard.
> 
> Testing: langtools/tools/jdeps.

Chen Liang has updated the pull request incrementally with two additional commits since the last revision:

 - Redundant library entry
 - Use test case to switch between flat dir and jar

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24604/files
  - new: https://git.openjdk.org/jdk/pull/24604/files/f61e9201..6a7cef62

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24604&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24604&range=02-03

  Stats: 28 lines in 1 file changed: 21 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24604.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24604/head:pull/24604

PR: https://git.openjdk.org/jdk/pull/24604

From joehw at openjdk.org  Mon Apr 21 16:19:30 2025
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 21 Apr 2025 16:19:30 GMT
Subject: RFR: 8354774: DocumentBuilderFactory getAttribute throws NPE [v3]
In-Reply-To: 
References: 
Message-ID: <9-jV2WryJyUFCGXMkH2hiOxKEaMM0f6wZxsocpXS2hs=.0cb47269-9054-4298-af44-0848e575ceb1@github.com>

> Fix a NPE on calling DocumentBuilderFactory::getAttribute, refer to the bug report.
> 
> Also in this patch: consolidates get and set properties to use the same Util methods to reduce potential errors when code changes.
> 
> Test:
>     Tier1 - 3 passed
>     JCK test passed

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  adjust spaces

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24732/files
  - new: https://git.openjdk.org/jdk/pull/24732/files/1b8ecd32..022611dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24732&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24732&range=01-02

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24732/head:pull/24732

PR: https://git.openjdk.org/jdk/pull/24732

From joehw at openjdk.org  Mon Apr 21 16:19:30 2025
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 21 Apr 2025 16:19:30 GMT
Subject: RFR: 8354774: DocumentBuilderFactory getAttribute throws NPE [v2]
In-Reply-To: 
References: 
 <0bAwDMoPMDTI66jUMmkU_Fo7oEW4XYIGbkYnJz3jK74=.991ad888-be65-422e-a2fd-b702fff5c437@github.com>
 
Message-ID: 

On Mon, 21 Apr 2025 08:11:33 GMT, Andrey Turbanov  wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove unused variable pName; remove unused imports
>
> src/java.xml/share/classes/jdk/xml/internal/JdkXmlUtils.java line 133:
> 
>> 131:             String property) {
>> 132:         String value = null;
>> 133:         if  (xsm != null && (value = xsm.getLimitAsString(property)) != null) {
> 
> Suggestion:
> 
>         if (xsm != null && (value = xsm.getLimitAsString(property)) != null) {

Thanks. Spaces adjusted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24732#discussion_r2052669398

From jpai at openjdk.org  Mon Apr 21 16:20:43 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 21 Apr 2025 16:20:43 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine [v4]
In-Reply-To: 
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
 
Message-ID: 

On Mon, 21 Apr 2025 16:06:25 GMT, Chen Liang  wrote:

>> When jdeps was migrated from old classfile to ClassFile API, the parsing semantic changed - error checks are now made lazily, and nested crashes from malformed signature or other problems is now latent, after a `ClassModel` instance is available. (The old error check existed only for constructing a `ClassModel`)
>> 
>> To address this issue, I have updated the way of iterating class files to be handler/consumer based like in the ClassFile API. This has the advantage that when one invocation of the handler fails of a `ClassFileError`, other invocations for other class files can proceed, and the exception handler has sufficient information to report a useful message indicating the source of error.
>> 
>> For the particular example of examining a proguard processed `dummy-scala.jar`, here is the new output of `jdeps dummy-scala.jar`:
>> 
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 59, expected an identifier: Lscala/collection/immutable/TreeMap$TreeMapBuilder.;: scala/collection/immutable/TreeMap$TreeMapBuilder.class (dummy-scala.jar)
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 49, expected an identifier: Lscala/collection/parallel/mutable/ParArray.;: scala/collection/parallel/mutable/ParArray.class (dummy-scala.jar)
>> 
>> 
>> Now, jdeps shows the bad class files. Inspection into the files reveal that proguard incorrectly deleted the simple class names with trailing `$`, for example, the original signature of the broken ParArray was `Lscala/collection/parallel/mutable/ParArray.ParArrayIterator$;`, so the `ParArrayIterator$` part was incorrectly dropped by proguard.
>> 
>> Testing: langtools/tools/jdeps.
>
> Chen Liang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Redundant library entry
>  - Use test case to switch between flat dir and jar

Thank you for adding this test. The updated test looks good to me and I believe it add the necessary coverage for this fix. 

Since this is a freshly added test, it would be good to run the relevant tier in our CI before integrating.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24604#pullrequestreview-2781701303

From liach at openjdk.org  Mon Apr 21 16:27:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Apr 2025 16:27:03 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine [v5]
In-Reply-To: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
Message-ID: 

> When jdeps was migrated from old classfile to ClassFile API, the parsing semantic changed - error checks are now made lazily, and nested crashes from malformed signature or other problems is now latent, after a `ClassModel` instance is available. (The old error check existed only for constructing a `ClassModel`)
> 
> To address this issue, I have updated the way of iterating class files to be handler/consumer based like in the ClassFile API. This has the advantage that when one invocation of the handler fails of a `ClassFileError`, other invocations for other class files can proceed, and the exception handler has sufficient information to report a useful message indicating the source of error.
> 
> For the particular example of examining a proguard processed `dummy-scala.jar`, here is the new output of `jdeps dummy-scala.jar`:
> 
> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 59, expected an identifier: Lscala/collection/immutable/TreeMap$TreeMapBuilder.;: scala/collection/immutable/TreeMap$TreeMapBuilder.class (dummy-scala.jar)
> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 49, expected an identifier: Lscala/collection/parallel/mutable/ParArray.;: scala/collection/parallel/mutable/ParArray.class (dummy-scala.jar)
> 
> 
> Now, jdeps shows the bad class files. Inspection into the files reveal that proguard incorrectly deleted the simple class names with trailing `$`, for example, the original signature of the broken ParArray was `Lscala/collection/parallel/mutable/ParArray.ParArrayIterator$;`, so the `ParArrayIterator$` part was incorrectly dropped by proguard.
> 
> Testing: langtools/tools/jdeps.

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 six additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/jdeps-bad-class-skip
 - Redundant library entry
 - Use test case to switch between flat dir and jar
 - Add a test
 - Review remarks
 - 8341608: jdeps in JDK 23 crashes when parsing signatures while jdeps in JDK 22 works fine

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24604/files
  - new: https://git.openjdk.org/jdk/pull/24604/files/6a7cef62..32bc0a32

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24604&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24604&range=03-04

  Stats: 190967 lines in 560 files changed: 20599 ins; 168910 del; 1458 mod
  Patch: https://git.openjdk.org/jdk/pull/24604.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24604/head:pull/24604

PR: https://git.openjdk.org/jdk/pull/24604

From liach at openjdk.org  Mon Apr 21 16:27:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Apr 2025 16:27:03 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine [v4]
In-Reply-To: 
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
 
Message-ID: 

On Mon, 21 Apr 2025 16:06:25 GMT, Chen Liang  wrote:

>> When jdeps was migrated from old classfile to ClassFile API, the parsing semantic changed - error checks are now made lazily, and nested crashes from malformed signature or other problems is now latent, after a `ClassModel` instance is available. (The old error check existed only for constructing a `ClassModel`)
>> 
>> To address this issue, I have updated the way of iterating class files to be handler/consumer based like in the ClassFile API. This has the advantage that when one invocation of the handler fails of a `ClassFileError`, other invocations for other class files can proceed, and the exception handler has sufficient information to report a useful message indicating the source of error.
>> 
>> For the particular example of examining a proguard processed `dummy-scala.jar`, here is the new output of `jdeps dummy-scala.jar`:
>> 
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 59, expected an identifier: Lscala/collection/immutable/TreeMap$TreeMapBuilder.;: scala/collection/immutable/TreeMap$TreeMapBuilder.class (dummy-scala.jar)
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 49, expected an identifier: Lscala/collection/parallel/mutable/ParArray.;: scala/collection/parallel/mutable/ParArray.class (dummy-scala.jar)
>> 
>> 
>> Now, jdeps shows the bad class files. Inspection into the files reveal that proguard incorrectly deleted the simple class names with trailing `$`, for example, the original signature of the broken ParArray was `Lscala/collection/parallel/mutable/ParArray.ParArrayIterator$;`, so the `ParArrayIterator$` part was incorrectly dropped by proguard.
>> 
>> Testing: langtools/tools/jdeps.
>
> Chen Liang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Redundant library entry
>  - Use test case to switch between flat dir and jar

Indeed, I will run tier 1 and 2 which seem to include all langtools tests after merging latest master (not merging mainline before integration is usually the cause of critical build or test failures)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24604#issuecomment-2818940119

From weijun at openjdk.org  Mon Apr 21 16:27:44 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 21 Apr 2025 16:27:44 GMT
Subject: RFR: 8354053: Remove unused JavaIOFilePermissionAccess [v2]
In-Reply-To: 
References: 
 
Message-ID: <77BHgOboZY2R-mS9jo2kgJO9QNPk0jvIskCxSuiHCtU=.6045b542-c8e2-44f7-ae66-8acdb897f6fa@github.com>

On Mon, 14 Apr 2025 16:14:03 GMT, Roger Riggs  wrote:

>> The JavaIOFilePermissionAccess interface is removed from SharedSecrets and its implementation (FilePermCompat.java) used by the test is moved to java.io FilePermission where cross package access is not needed. 
>> The test FilePermissionCollectionMerge is updated to access the internal implementation in FilePermission. 
>> Modernized the initialization from the system property `jdk.io.permissionsUseCanonicalPath`. 
>> The remaining support will be removed when FilePermission is removed.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify as suggested in review comments
>   Convert static methods to instance methods and invoke on the existing FilePermission.

LGTM. In fact, there is no need to keep or test on `newPermPlusAltPath` and `newPermUsingAltPath`. Those were only used in access control checks with the "new" behavior.

-------------

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24603#pullrequestreview-2781713842

From jpai at openjdk.org  Mon Apr 21 16:45:43 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 21 Apr 2025 16:45:43 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine [v5]
In-Reply-To: 
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
 
Message-ID: 

On Mon, 21 Apr 2025 16:27:03 GMT, Chen Liang  wrote:

>> When jdeps was migrated from old classfile to ClassFile API, the parsing semantic changed - error checks are now made lazily, and nested crashes from malformed signature or other problems is now latent, after a `ClassModel` instance is available. (The old error check existed only for constructing a `ClassModel`)
>> 
>> To address this issue, I have updated the way of iterating class files to be handler/consumer based like in the ClassFile API. This has the advantage that when one invocation of the handler fails of a `ClassFileError`, other invocations for other class files can proceed, and the exception handler has sufficient information to report a useful message indicating the source of error.
>> 
>> For the particular example of examining a proguard processed `dummy-scala.jar`, here is the new output of `jdeps dummy-scala.jar`:
>> 
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 59, expected an identifier: Lscala/collection/immutable/TreeMap$TreeMapBuilder.;: scala/collection/immutable/TreeMap$TreeMapBuilder.class (dummy-scala.jar)
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 49, expected an identifier: Lscala/collection/parallel/mutable/ParArray.;: scala/collection/parallel/mutable/ParArray.class (dummy-scala.jar)
>> 
>> 
>> Now, jdeps shows the bad class files. Inspection into the files reveal that proguard incorrectly deleted the simple class names with trailing `$`, for example, the original signature of the broken ParArray was `Lscala/collection/parallel/mutable/ParArray.ParArrayIterator$;`, so the `ParArrayIterator$` part was incorrectly dropped by proguard.
>> 
>> Testing: langtools/tools/jdeps.
>
> 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 six additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/jdeps-bad-class-skip
>  - Redundant library entry
>  - Use test case to switch between flat dir and jar
>  - Add a test
>  - Review remarks
>  - 8341608: jdeps in JDK 23 crashes when parsing signatures while jdeps in JDK 22 works fine

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24604#pullrequestreview-2781747490

From jengebr at amazon.com  Mon Apr 21 16:46:22 2025
From: jengebr at amazon.com (Engebretson, John)
Date: Mon, 21 Apr 2025 16:46:22 +0000
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: <0249c80513c74209b34b63cce0f7a2c8@amazon.com>
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 
 <1aa3d217-2bf0-4bba-8801-f44c4d175423@headcrashing.eu>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 
 
 <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
 
 <3f1c69a7ac5946809d2af850d7d59db9@amazon.com>
 
 
 
 <4741eceb3beb40c2bc82613c67836d66@amazon.com>
 
 
 
 <4c4aac5737d844a4959885c65f17efee@amazon.com>
 <0249c80513c74209b34b63cce0f7a2c8@amazon.com>
Message-ID: <4d239bc7086c49f6b56f9b3c741f13c6@amazon.com>

  Following up on MemoryOutputStream, etc. ? the conversation has considered a few alternatives:

1. Hide the new class behind ByteArrayOutputStream.unsynchronized()
2. Create a new public class providing views to OutputStream, Channel, InputStream
3. Something to do with an Object[] variant

  I would personally reject any code review that used ?unsynchronized()? to describe this class, since that is only a minor property of the change.  I could live with ?scalable? or something along those lines.
  A new public class provides more capabilities than I initially proposed, but of course requires a new public class.  ?
  The Object[] variant is interesting but I have no pressing need for it.  This probably gets a pin in it unless someone provides a use case.

    Thoughts appreciated.  Thanks!
      John


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From naoto at openjdk.org  Mon Apr 21 17:28:54 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 21 Apr 2025 17:28:54 GMT
Subject: RFR: 8354774: DocumentBuilderFactory getAttribute throws NPE [v3]
In-Reply-To: <9-jV2WryJyUFCGXMkH2hiOxKEaMM0f6wZxsocpXS2hs=.0cb47269-9054-4298-af44-0848e575ceb1@github.com>
References: 
 <9-jV2WryJyUFCGXMkH2hiOxKEaMM0f6wZxsocpXS2hs=.0cb47269-9054-4298-af44-0848e575ceb1@github.com>
Message-ID: 

On Mon, 21 Apr 2025 16:19:30 GMT, Joe Wang  wrote:

>> Fix a NPE on calling DocumentBuilderFactory::getAttribute, refer to the bug report.
>> 
>> Also in this patch: consolidates get and set properties to use the same Util methods to reduce potential errors when code changes.
>> 
>> Test:
>>     Tier1 - 3 passed
>>     JCK test passed
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust spaces

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24732#pullrequestreview-2781828554

From lancea at openjdk.org  Mon Apr 21 17:36:46 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 21 Apr 2025 17:36:46 GMT
Subject: RFR: 8354774: DocumentBuilderFactory getAttribute throws NPE [v3]
In-Reply-To: <9-jV2WryJyUFCGXMkH2hiOxKEaMM0f6wZxsocpXS2hs=.0cb47269-9054-4298-af44-0848e575ceb1@github.com>
References: 
 <9-jV2WryJyUFCGXMkH2hiOxKEaMM0f6wZxsocpXS2hs=.0cb47269-9054-4298-af44-0848e575ceb1@github.com>
Message-ID: 

On Mon, 21 Apr 2025 16:19:30 GMT, Joe Wang  wrote:

>> Fix a NPE on calling DocumentBuilderFactory::getAttribute, refer to the bug report.
>> 
>> Also in this patch: consolidates get and set properties to use the same Util methods to reduce potential errors when code changes.
>> 
>> Test:
>>     Tier1 - 3 passed
>>     JCK test passed
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust spaces

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24732#pullrequestreview-2781842304

From liach at openjdk.org  Mon Apr 21 17:42:33 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Apr 2025 17:42:33 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine [v6]
In-Reply-To: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
Message-ID: 

> When jdeps was migrated from old classfile to ClassFile API, the parsing semantic changed - error checks are now made lazily, and nested crashes from malformed signature or other problems is now latent, after a `ClassModel` instance is available. (The old error check existed only for constructing a `ClassModel`)
> 
> To address this issue, I have updated the way of iterating class files to be handler/consumer based like in the ClassFile API. This has the advantage that when one invocation of the handler fails of a `ClassFileError`, other invocations for other class files can proceed, and the exception handler has sufficient information to report a useful message indicating the source of error.
> 
> For the particular example of examining a proguard processed `dummy-scala.jar`, here is the new output of `jdeps dummy-scala.jar`:
> 
> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 59, expected an identifier: Lscala/collection/immutable/TreeMap$TreeMapBuilder.;: scala/collection/immutable/TreeMap$TreeMapBuilder.class (dummy-scala.jar)
> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 49, expected an identifier: Lscala/collection/parallel/mutable/ParArray.;: scala/collection/parallel/mutable/ParArray.class (dummy-scala.jar)
> 
> 
> Now, jdeps shows the bad class files. Inspection into the files reveal that proguard incorrectly deleted the simple class names with trailing `$`, for example, the original signature of the broken ParArray was `Lscala/collection/parallel/mutable/ParArray.ParArrayIterator$;`, so the `ParArrayIterator$` part was incorrectly dropped by proguard.
> 
> Testing: langtools/tools/jdeps.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Use simple file name due to windows directory separators

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24604/files
  - new: https://git.openjdk.org/jdk/pull/24604/files/32bc0a32..a2b1dc70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24604&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24604&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24604.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24604/head:pull/24604

PR: https://git.openjdk.org/jdk/pull/24604

From liach at openjdk.org  Mon Apr 21 17:52:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Apr 2025 17:52:44 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine [v6]
In-Reply-To: 
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
 
Message-ID: 

On Mon, 21 Apr 2025 17:42:33 GMT, Chen Liang  wrote:

>> When jdeps was migrated from old classfile to ClassFile API, the parsing semantic changed - error checks are now made lazily, and nested crashes from malformed signature or other problems is now latent, after a `ClassModel` instance is available. (The old error check existed only for constructing a `ClassModel`)
>> 
>> To address this issue, I have updated the way of iterating class files to be handler/consumer based like in the ClassFile API. This has the advantage that when one invocation of the handler fails of a `ClassFileError`, other invocations for other class files can proceed, and the exception handler has sufficient information to report a useful message indicating the source of error.
>> 
>> For the particular example of examining a proguard processed `dummy-scala.jar`, here is the new output of `jdeps dummy-scala.jar`:
>> 
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 59, expected an identifier: Lscala/collection/immutable/TreeMap$TreeMapBuilder.;: scala/collection/immutable/TreeMap$TreeMapBuilder.class (dummy-scala.jar)
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 49, expected an identifier: Lscala/collection/parallel/mutable/ParArray.;: scala/collection/parallel/mutable/ParArray.class (dummy-scala.jar)
>> 
>> 
>> Now, jdeps shows the bad class files. Inspection into the files reveal that proguard incorrectly deleted the simple class names with trailing `$`, for example, the original signature of the broken ParArray was `Lscala/collection/parallel/mutable/ParArray.ParArrayIterator$;`, so the `ParArrayIterator$` part was incorrectly dropped by proguard.
>> 
>> Testing: langtools/tools/jdeps.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use simple file name due to windows directory separators

The improper path separator in the new test is causing test failure in windows. Updated and fixed it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24604#issuecomment-2819120641

From joehw at openjdk.org  Mon Apr 21 18:28:50 2025
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 21 Apr 2025 18:28:50 GMT
Subject: Integrated: 8354774: DocumentBuilderFactory getAttribute throws NPE
In-Reply-To: 
References: 
Message-ID: 

On Thu, 17 Apr 2025 17:41:56 GMT, Joe Wang  wrote:

> Fix a NPE on calling DocumentBuilderFactory::getAttribute, refer to the bug report.
> 
> Also in this patch: consolidates get and set properties to use the same Util methods to reduce potential errors when code changes.
> 
> Test:
>     Tier1 - 3 passed
>     JCK test passed

This pull request has now been integrated.

Changeset: 684d3b33
Author:    Joe Wang 
URL:       https://git.openjdk.org/jdk/commit/684d3b336e9cb31707d35e75f9b785e04e1fdbee
Stats:     339 lines in 11 files changed: 219 ins; 71 del; 49 mod

8354774: DocumentBuilderFactory getAttribute throws NPE

Reviewed-by: naoto, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/24732

From iklam at openjdk.org  Mon Apr 21 18:42:40 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 21 Apr 2025 18:42:40 GMT
Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 21 Apr 2025 06:20:46 GMT, Calvin Cheung  wrote:

>> This RFE allows --add-opens to be specified for AOT cache creation. AOT cache can be used during production run with --add-opens option as long as the same set of options is used during assembly phase.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @iklam comment

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 165:

> 163:             BootLoader.getUnnamedModule(); // trigger  of BootLoader.
> 164:             CDS.defineArchivedModules(ClassLoaders.platformClassLoader(), ClassLoaders.appClassLoader());
> 165:             boolean extraExportsOrOpens = addExtraExportsAndOpens(bootLayer);

(1) The returned value of `addExtraExportsAndOpens()` is not used. So I think this function can be changed to `void`, and all occurrences of the local variable `extraExportsOrOpens` can be removed.

(2) I traced the code paths that depend on the effects of `--add-opens` and `--add-exports`. It Looks like some of the effects are recorded in the `java.lang.Module$ReflectionData::export` table:

https://github.com/openjdk/jdk/blob/684d3b336e9cb31707d35e75f9b785e04e1fdbee/src/java.base/share/classes/java/lang/Module.java#L398C2-L412


        /**
         * A module (1st key) exports or opens a package to another module
         * (2nd key). The map value is a map of package name to a boolean
         * that indicates if the package is opened.
         */
        static final WeakPairMap> exports =
            new WeakPairMap<>();


This table is *not* stored as part of the `ArchivedBootLayer`, so we must re-initialize this table in the production run. @AlanBateman could you confirm that this is correct.

Eventually, we should enhance the `ArchivedBootLayer` to also include the tables in `Module$ReflectionData`. That will obviate the call to `addExtraExportsAndOpens()` and save a few bytecodes during start-up (but the overall impact would be small, so it's not critical in the current PR). Because these tables use WeakReference, we need to wait for [JDK-8354897](https://bugs.openjdk.org/browse/JDK-8354897).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24695#discussion_r2052840896

From iklam at openjdk.org  Mon Apr 21 18:46:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 21 Apr 2025 18:46:41 GMT
Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 21 Apr 2025 06:20:46 GMT, Calvin Cheung  wrote:

>> This RFE allows --add-opens to be specified for AOT cache creation. AOT cache can be used during production run with --add-opens option as long as the same set of options is used during assembly phase.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @iklam comment

test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/AddOpens.java line 109:

> 107:                             "--add-opens", addOpensArg,
> 108:                             "--module-path", moduleDir.toString(),
> 109:                             "-m", TEST_MODULE1, "with_add_opens")

Could you add a test case for `=ALL-UNNAMED` as well? That is frequently used by applications, and it takes a different code path inside the implementation.

I think this can be done by running `com.simple.Main` in the classpath rather than module path.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24695#discussion_r2052848888

From darcy at openjdk.org  Mon Apr 21 19:08:41 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 21 Apr 2025 19:08:41 GMT
Subject: RFR: 8354424: java/util/logging/LoggingDeadlock5.java fails
 intermittently in tier6 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 16 Apr 2025 17:37:07 GMT, David Beaumont  wrote:

>> Increasing timeout for deadlock detection and adjusting for the timeout factor in higher tiers.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing test from the problem list.

test/jdk/java/util/logging/LoggingDeadlock5.java line 127:

> 125:         // in higher tiers, so it's necessary to be a bit pessimistic here.
> 126:         private final static Duration JOIN_WAIT =
> 127:                 Duration.ofMillis(Utils.adjustTimeout(2000));

Just checking, adjustTimeout does scaling based on the timeout factor given to jtreg?

What happens to the expected test running time to the test in lower tiers without as high loads?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24687#discussion_r2052873175

From vromero at openjdk.org  Mon Apr 21 19:20:53 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 21 Apr 2025 19:20:53 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 01:03:01 GMT, Jan Lahoda  wrote:

>> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
>> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
>> - `java. ... .IO` is no longer automatically imported in any compilation unit
>> - the feature is finalized (i.e. no longer requires `--enable-preview`)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add clause about handling of malformed/unmappable bytes.

lgtm

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24438#pullrequestreview-2782056620

From liach at openjdk.org  Mon Apr 21 19:34:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Apr 2025 19:34:49 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate
Message-ID: 

In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list".

-------------

Commit messages:
 - 8355223: Improve documentation on @IntrinsicCandidate

Changes: https://git.openjdk.org/jdk/pull/24777/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24777&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355223
  Stats: 91 lines in 1 file changed: 4 ins; 65 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/24777.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24777/head:pull/24777

PR: https://git.openjdk.org/jdk/pull/24777

From bpb at openjdk.org  Mon Apr 21 19:55:06 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 21 Apr 2025 19:55:06 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v7]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: 

> Implement the requested methods and add a test thereof.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8354724: readString -> readAllChars; update test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/b9424bb4..b2c3481a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=05-06

  Stats: 20 lines in 2 files changed: 11 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728

PR: https://git.openjdk.org/jdk/pull/24728

From bpb at openjdk.org  Mon Apr 21 19:55:06 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 21 Apr 2025 19:55:06 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v6]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
Message-ID: 

On Mon, 21 Apr 2025 08:17:30 GMT, Andrey Turbanov  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8354724: Remove unused import
>
> test/jdk/java/io/BufferedReader/ReadAll.java line 70:
> 
>> 68:         int size = rnd.nextInt(2, 16386);
>> 69: 
>> 70:         try (FileChannel fc = FileChannel.open(path, CREATE, WRITE);) {
> 
> Suggestion:
> 
>         try (FileChannel fc = FileChannel.open(path, CREATE, WRITE)) {

Fixed in b2c3481.

> test/jdk/java/io/BufferedReader/ReadAll.java line 104:
> 
>> 102:         List lines;
>> 103:         try (FileReader fr = new FileReader(file);
>> 104:              BufferedReader br = new BufferedReader(fr);) {
> 
> Suggestion:
> 
>              BufferedReader br = new BufferedReader(fr)) {

Fixed in b2c3481.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2052920558
PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2052920752

From liach at openjdk.org  Mon Apr 21 20:12:19 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Apr 2025 20:12:19 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v2]
In-Reply-To: 
References: 
Message-ID: 

> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list".

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Refine validation and defensive copying

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24777/files
  - new: https://git.openjdk.org/jdk/pull/24777/files/6e8b3254..e8adab3c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24777&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24777&range=00-01

  Stats: 9 lines in 1 file changed: 1 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/24777.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24777/head:pull/24777

PR: https://git.openjdk.org/jdk/pull/24777

From naoto at openjdk.org  Mon Apr 21 20:16:16 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 21 Apr 2025 20:16:16 GMT
Subject: RFR: 8355215: Add @spec tags to Emoji related methods
Message-ID: 

Adding @spec tags to Emoji related methods in the Character class. A CSR has also been drafted.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/24779/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24779&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355215
  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24779/head:pull/24779

PR: https://git.openjdk.org/jdk/pull/24779

From bpb at openjdk.org  Mon Apr 21 20:22:45 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 21 Apr 2025 20:22:45 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v5]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
 
 
 
 <-Xv5K_oAaVhe3ppb3GV_Vo_cc5r7G4aWjbi-k09FwIk=.91ff9d1e-f8e2-4422-b203-4d0cb13c24cf@github.com>
 
 
Message-ID: 

On Fri, 18 Apr 2025 15:10:02 GMT, Chen Liang  wrote:

>> Maybe it can be implemented by referring to `InputStream::readNBytes(int)` (The default implementation of `InputStream::readAllBytes()` is based on it):
>> 
>> https://github.com/openjdk/jdk/blob/22e8a97a1ce4e1c781fbc6f1e271c477fe95f069/src/java.base/share/classes/java/io/InputStream.java#L396-L458
>
> If accumulation of array is necessary, I think the "variable sized array" in #24232 may help/

https://github.com/openjdk/jdk/pull/24728#issuecomment-2815687444

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2052949330

From jlu at openjdk.org  Mon Apr 21 20:26:54 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 21 Apr 2025 20:26:54 GMT
Subject: Integrated: 8354344: Test behavior after cut-over for future ISO 4217
 currency
In-Reply-To: 
References: 
Message-ID: 

On Wed, 16 Apr 2025 23:06:19 GMT, Justin Lu  wrote:

> Please review this PR which improves the _ValidateISO4217_ Currency test by adding testing of future currencies after the transition date.
> 
> This is done by creating a patched version of Currency that replaces `System.currentTimeMillis()` calls with a mocked value equivalent to `Long.MAX_VALUE`. A module patch is then applied to supply the new Currency class files.
> 
> The mocked time behavior is tested by using the `currency.properties` override in a separate invocation.

This pull request has now been integrated.

Changeset: 1526dd81
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/1526dd81d9b5bf4abaac1546c370cf7a056d01dc
Stats:     133 lines in 2 files changed: 128 ins; 1 del; 4 mod

8354344: Test behavior after cut-over for future ISO 4217 currency

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/24701

From bpb at openjdk.org  Mon Apr 21 20:47:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 21 Apr 2025 20:47:38 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v8]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: 

> Implement the requested methods and add a test thereof.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8354724: Change "lines" to "characters" in spec of Reader.readAllChars, where appropriate

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/b2c3481a..d35d9ebb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=06-07

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728

PR: https://git.openjdk.org/jdk/pull/24728

From joehw at openjdk.org  Mon Apr 21 21:03:54 2025
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 21 Apr 2025 21:03:54 GMT
Subject: RFR: 8355215: Add @spec tags to Emoji related methods
In-Reply-To: 
References: 
Message-ID: 

On Mon, 21 Apr 2025 20:11:47 GMT, Naoto Sato  wrote:

> Adding @spec tags to Emoji related methods in the Character class. A CSR has also been drafted.

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24779#pullrequestreview-2782236067

From iris at openjdk.org  Mon Apr 21 21:03:55 2025
From: iris at openjdk.org (Iris Clark)
Date: Mon, 21 Apr 2025 21:03:55 GMT
Subject: RFR: 8355215: Add @spec tags to Emoji related methods
In-Reply-To: 
References: 
Message-ID: <0_cJxrcWa57BtkpHk4OQF7TRZ1M-WwCGgPG9fYQbrKo=.8a3b5b68-d014-4640-b5ab-4c2fed25cee4@github.com>

On Mon, 21 Apr 2025 20:11:47 GMT, Naoto Sato  wrote:

> Adding @spec tags to Emoji related methods in the Character class. A CSR has also been drafted.

CSR also Reviewed.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24779#pullrequestreview-2782238754

From asemenyuk at openjdk.org  Mon Apr 21 21:34:59 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 21 Apr 2025 21:34:59 GMT
Subject: RFR: 8354990: Improve negative tests coverage for jpackage signing
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Add tests for the following test cases:
>  - Expired certificate specified for signing;
>  - Multiple certificates with the same name in one keychain.
> 
> Adding the new tests revealed an issue with MacCertificate - [JDK-8354989](https://bugs.openjdk.org/browse/JDK-8354989). This issue is also addressed in this PR.
> 
> Additionally:
>  - Moved code to verify signatures in MacSignVerify class and reworked SigningBase verify functions to use MacSignVerify API.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Fix compilation error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24762/files
  - new: https://git.openjdk.org/jdk/pull/24762/files/f60e1da8..95a45098

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24762&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24762&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24762.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24762/head:pull/24762

PR: https://git.openjdk.org/jdk/pull/24762

From asemenyuk at openjdk.org  Mon Apr 21 21:34:59 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 21 Apr 2025 21:34:59 GMT
Subject: RFR: 8354990: Improve negative tests coverage for jpackage signing
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Apr 2025 21:11:35 GMT, Alexey Semenyuk  wrote:

> Add tests for the following test cases:
>  - Expired certificate specified for signing;
>  - Multiple certificates with the same name in one keychain.
> 
> Adding the new tests revealed an issue with MacCertificate - [JDK-8354989](https://bugs.openjdk.org/browse/JDK-8354989). This issue is also addressed in this PR.
> 
> Additionally:
>  - Moved code to verify signatures in MacSignVerify class and reworked SigningBase verify functions to use MacSignVerify API.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24762#issuecomment-2819546107

From jlu at openjdk.org  Mon Apr 21 21:53:42 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 21 Apr 2025 21:53:42 GMT
Subject: RFR: 8355215: Add @spec tags to Emoji related methods
In-Reply-To: 
References: 
Message-ID: 

On Mon, 21 Apr 2025 20:11:47 GMT, Naoto Sato  wrote:

> Adding @spec tags to Emoji related methods in the Character class. A CSR has also been drafted.

Marked as reviewed by jlu (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24779#pullrequestreview-2782310737

From jlu at openjdk.org  Mon Apr 21 21:56:59 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 21 Apr 2025 21:56:59 GMT
Subject: RFR: 8354343: Hardening of Currency tests for not yet defined future
 ISO 4217 currency
Message-ID: 

Please review this PR which improves future currency checking for ISO 4217 currencies.

Checking for a currency that should not yet exist in the set of available currencies is already done.
It should also be explicitly checked that such a currency can not be instantiated as well via the String getter.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/24782/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24782&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354343
  Stats: 35 lines in 1 file changed: 34 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24782.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24782/head:pull/24782

PR: https://git.openjdk.org/jdk/pull/24782

From naoto at openjdk.org  Mon Apr 21 22:34:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 21 Apr 2025 22:34:51 GMT
Subject: RFR: 8354343: Hardening of Currency tests for not yet defined
 future ISO 4217 currency
In-Reply-To: 
References: 
Message-ID: <-7U0IsIhO6ZZR8u31uYAOOJDCyd7fOdhWQ0DD46btQE=.e795cf83-6ef6-4f9f-8517-73c30d15fdbe@github.com>

On Mon, 21 Apr 2025 21:51:35 GMT, Justin Lu  wrote:

> Please review this PR which improves future currency checking for ISO 4217 currencies.
> 
> Checking for a currency that should not yet exist in the set of available currencies is already done.
> It should also be explicitly checked that such a currency can not be instantiated as well via the String getter.

LGTM. I think this JIRA issue and the previous test improvement one can be linke to [JDK-8321480](https://bugs.openjdk.org/browse/JDK-8321480), and both have `iso4217` lables.

test/jdk/java/util/Currency/ValidateISO4217.java line 183:

> 181:         setUpPatchedClasses();
> 182:         setUpTestingData();
> 183:         setUpNotYetDefined();

It may be clearer to move this inside `setUpTestingData()`, and modify the comment there

-------------

PR Review: https://git.openjdk.org/jdk/pull/24782#pullrequestreview-2782347271
PR Review Comment: https://git.openjdk.org/jdk/pull/24782#discussion_r2053062123

From ccheung at openjdk.org  Mon Apr 21 22:58:04 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 21 Apr 2025 22:58:04 GMT
Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking [v4]
In-Reply-To: 
References: 
Message-ID: 

> This RFE allows --add-opens to be specified for AOT cache creation. AOT cache can be used during production run with --add-opens option as long as the same set of options is used during assembly phase.
> 
> Passed tiers 1 - 4 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  @iklam comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24695/files
  - new: https://git.openjdk.org/jdk/pull/24695/files/2ae685f8..95f2e9c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24695&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24695&range=02-03

  Stats: 35 lines in 2 files changed: 18 ins; 6 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/24695.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24695/head:pull/24695

PR: https://git.openjdk.org/jdk/pull/24695

From ccheung at openjdk.org  Mon Apr 21 22:58:04 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 21 Apr 2025 22:58:04 GMT
Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <9ov8LzpXXaWjbX9tGNGgyHp5QZIrLateO1f40JxRdGY=.3a841ff1-10c8-466c-a1e0-fc5548a1076f@github.com>

On Mon, 21 Apr 2025 18:39:39 GMT, Ioi Lam  wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @iklam comment
>
> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 165:
> 
>> 163:             BootLoader.getUnnamedModule(); // trigger  of BootLoader.
>> 164:             CDS.defineArchivedModules(ClassLoaders.platformClassLoader(), ClassLoaders.appClassLoader());
>> 165:             boolean extraExportsOrOpens = addExtraExportsAndOpens(bootLayer);
> 
> (1) The returned value of `addExtraExportsAndOpens()` is not used. So I think this function can be changed to `void`, and all occurrences of the local variable `extraExportsOrOpens` can be removed.
> 
> (2) I traced the code paths that depend on the effects of `--add-opens` and `--add-exports`. It Looks like some of the effects are recorded in the `java.lang.Module$ReflectionData::export` table:
> 
> https://github.com/openjdk/jdk/blob/684d3b336e9cb31707d35e75f9b785e04e1fdbee/src/java.base/share/classes/java/lang/Module.java#L398C2-L412
> 
> 
>         /**
>          * A module (1st key) exports or opens a package to another module
>          * (2nd key). The map value is a map of package name to a boolean
>          * that indicates if the package is opened.
>          */
>         static final WeakPairMap> exports =
>             new WeakPairMap<>();
> 
> 
> This table is *not* stored as part of the `ArchivedBootLayer`, so we must re-initialize this table in the production run. @AlanBateman could you confirm that this is correct.
> 
> Eventually, we should enhance the `ArchivedBootLayer` to also include the tables in `Module$ReflectionData`. That will obviate the call to `addExtraExportsAndOpens()` and save a few bytecodes during start-up (but the overall impact would be small, so it's not critical in the current PR). Because these tables use WeakReference, we need to wait for [JDK-8354897](https://bugs.openjdk.org/browse/JDK-8354897).

Fixed (1) above.

> test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/AddOpens.java line 109:
> 
>> 107:                             "--add-opens", addOpensArg,
>> 108:                             "--module-path", moduleDir.toString(),
>> 109:                             "-m", TEST_MODULE1, "with_add_opens")
> 
> Could you add a test case for `=ALL-UNNAMED` as well? That is frequently used by applications, and it takes a different code path inside the implementation.
> 
> I think this can be done by running `com.simple.Main` in the classpath rather than module path.

Added the test case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24695#discussion_r2053082635
PR Review Comment: https://git.openjdk.org/jdk/pull/24695#discussion_r2053082907

From jlu at openjdk.org  Mon Apr 21 23:15:56 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 21 Apr 2025 23:15:56 GMT
Subject: RFR: 8354343: Hardening of Currency tests for not yet defined
 future ISO 4217 currency [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which improves future currency checking for ISO 4217 currencies.
> 
> Checking for a currency that should not yet exist in the set of available currencies is already done.
> It should also be explicitly checked that such a currency can not be instantiated as well via the String getter.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  move future currencies set up under setUpTestingData()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24782/files
  - new: https://git.openjdk.org/jdk/pull/24782/files/7424e964..6c4cbe94

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24782&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24782&range=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24782.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24782/head:pull/24782

PR: https://git.openjdk.org/jdk/pull/24782

From jlu at openjdk.org  Mon Apr 21 23:15:56 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 21 Apr 2025 23:15:56 GMT
Subject: RFR: 8354343: Hardening of Currency tests for not yet defined
 future ISO 4217 currency [v2]
In-Reply-To: <-7U0IsIhO6ZZR8u31uYAOOJDCyd7fOdhWQ0DD46btQE=.e795cf83-6ef6-4f9f-8517-73c30d15fdbe@github.com>
References: 
 <-7U0IsIhO6ZZR8u31uYAOOJDCyd7fOdhWQ0DD46btQE=.e795cf83-6ef6-4f9f-8517-73c30d15fdbe@github.com>
Message-ID: 

On Mon, 21 Apr 2025 22:25:14 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move future currencies set up under setUpTestingData()
>
> test/jdk/java/util/Currency/ValidateISO4217.java line 183:
> 
>> 181:         setUpPatchedClasses();
>> 182:         setUpTestingData();
>> 183:         setUpNotYetDefined();
> 
> It may be clearer to move this inside `setUpTestingData()`, and modify the comment there

Right, makes more sense that way. Also updated the JBS issues as you requested.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24782#discussion_r2053093655

From almatvee at openjdk.org  Mon Apr 21 23:53:46 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 21 Apr 2025 23:53:46 GMT
Subject: RFR: 8354990: Improve negative tests coverage for jpackage signing
 [v2]
In-Reply-To: 
References: 
 
Message-ID: <6UXfPj99bczO1OXsmZ1t7F8BwDtLtqOEgHeR4tv_pjY=.a48f7061-aca3-42ea-8f7a-a6f599a3f721@github.com>

On Mon, 21 Apr 2025 21:34:59 GMT, Alexey Semenyuk  wrote:

>> Add tests for the following test cases:
>>  - Expired certificate specified for signing;
>>  - Multiple certificates with the same name in one keychain.
>> 
>> Adding the new tests revealed an issue with MacCertificate - [JDK-8354989](https://bugs.openjdk.org/browse/JDK-8354989). This issue is also addressed in this PR.
>> 
>> Additionally:
>>  - Moved code to verify signatures in MacSignVerify class and reworked SigningBase verify functions to use MacSignVerify API.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation error

Looks good with minor comments.

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSign.java line 410:

> 408:                         continue;
> 409:                     }
> 410:                     certs.add(cert);

Maybe:

                    try {
                        final X509Certificate cert = (X509Certificate)CERT_FACTORY.generateCertificate(in);
                        certs.add(cert);
                    } catch (Exception ex) {
                        TKit.trace("Failed to parse certificate data: " + ex);                        
                    }

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSign.java line 691:

> 689:         }
> 690: 
> 691:         public String value( ) {

Extra space between `()`.

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSign.java line 705:

> 703:     }
> 704: 
> 705:     public record CertificateRequest(String name, CertificateType type, int days, boolean expired, boolean trusted) implements Comparable{

Space before `{`.

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSign.java line 733:

> 731:             } else if (expired) {
> 732:                 return VerifyStatus.VERIFY_EXPIRED;
> 733:             }else {

Formating.

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSign.java line 823:

> 821:     }
> 822: 
> 823:     private record InstalledCertificate(String name, CertificateType type, int days, boolean expired) implements Comparable{

Space before `{`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24762#pullrequestreview-2782360440
PR Review Comment: https://git.openjdk.org/jdk/pull/24762#discussion_r2053070383
PR Review Comment: https://git.openjdk.org/jdk/pull/24762#discussion_r2053087453
PR Review Comment: https://git.openjdk.org/jdk/pull/24762#discussion_r2053087987
PR Review Comment: https://git.openjdk.org/jdk/pull/24762#discussion_r2053088479
PR Review Comment: https://git.openjdk.org/jdk/pull/24762#discussion_r2053089845

From asemenyuk at openjdk.org  Tue Apr 22 00:05:46 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 22 Apr 2025 00:05:46 GMT
Subject: RFR: 8354990: Improve negative tests coverage for jpackage signing
 [v2]
In-Reply-To: <6UXfPj99bczO1OXsmZ1t7F8BwDtLtqOEgHeR4tv_pjY=.a48f7061-aca3-42ea-8f7a-a6f599a3f721@github.com>
References: 
 
 <6UXfPj99bczO1OXsmZ1t7F8BwDtLtqOEgHeR4tv_pjY=.a48f7061-aca3-42ea-8f7a-a6f599a3f721@github.com>
Message-ID: 

On Mon, 21 Apr 2025 22:36:08 GMT, Alexander Matveev  wrote:

>> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation error
>
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSign.java line 410:
> 
>> 408:                         continue;
>> 409:                     }
>> 410:                     certs.add(cert);
> 
> Maybe:
> 
>                     try {
>                         final X509Certificate cert = (X509Certificate)CERT_FACTORY.generateCertificate(in);
>                         certs.add(cert);
>                     } catch (Exception ex) {
>                         TKit.trace("Failed to parse certificate data: " + ex);                        
>                     }

This will combine certificate creation and adding it to the list of certificates. If the latter fails, this is not a `Failed to parse certificate data` error.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24762#discussion_r2053129886

From asemenyuk at openjdk.org  Tue Apr 22 00:14:17 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 22 Apr 2025 00:14:17 GMT
Subject: RFR: 8354990: Improve negative tests coverage for jpackage signing
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> Add tests for the following test cases:
>  - Expired certificate specified for signing;
>  - Multiple certificates with the same name in one keychain.
> 
> Adding the new tests revealed an issue with MacCertificate - [JDK-8354989](https://bugs.openjdk.org/browse/JDK-8354989). This issue is also addressed in this PR.
> 
> Additionally:
>  - Moved code to verify signatures in MacSignVerify class and reworked SigningBase verify functions to use MacSignVerify API.

Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:

 - Fix formatting
 - Fix formatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24762/files
  - new: https://git.openjdk.org/jdk/pull/24762/files/95a45098..8630b47c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24762&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24762&range=01-02

  Stats: 11 lines in 1 file changed: 2 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/24762.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24762/head:pull/24762

PR: https://git.openjdk.org/jdk/pull/24762

From asemenyuk at openjdk.org  Tue Apr 22 00:14:18 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 22 Apr 2025 00:14:18 GMT
Subject: RFR: 8354990: Improve negative tests coverage for jpackage signing
 [v2]
In-Reply-To: <6UXfPj99bczO1OXsmZ1t7F8BwDtLtqOEgHeR4tv_pjY=.a48f7061-aca3-42ea-8f7a-a6f599a3f721@github.com>
References: 
 
 <6UXfPj99bczO1OXsmZ1t7F8BwDtLtqOEgHeR4tv_pjY=.a48f7061-aca3-42ea-8f7a-a6f599a3f721@github.com>
Message-ID: 

On Mon, 21 Apr 2025 23:02:33 GMT, Alexander Matveev  wrote:

>> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation error
>
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSign.java line 691:
> 
>> 689:         }
>> 690: 
>> 691:         public String value( ) {
> 
> Extra space between `()`.

Fixed

> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSign.java line 705:
> 
>> 703:     }
>> 704: 
>> 705:     public record CertificateRequest(String name, CertificateType type, int days, boolean expired, boolean trusted) implements Comparable{
> 
> Space before `{`.

Fixed

> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSign.java line 733:
> 
>> 731:             } else if (expired) {
>> 732:                 return VerifyStatus.VERIFY_EXPIRED;
>> 733:             }else {
> 
> Formating.

Fixed

> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSign.java line 823:
> 
>> 821:     }
>> 822: 
>> 823:     private record InstalledCertificate(String name, CertificateType type, int days, boolean expired) implements Comparable{
> 
> Space before `{`.

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24762#discussion_r2053134171
PR Review Comment: https://git.openjdk.org/jdk/pull/24762#discussion_r2053134256
PR Review Comment: https://git.openjdk.org/jdk/pull/24762#discussion_r2053134094
PR Review Comment: https://git.openjdk.org/jdk/pull/24762#discussion_r2053134012

From almatvee at openjdk.org  Tue Apr 22 00:18:46 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 22 Apr 2025 00:18:46 GMT
Subject: RFR: 8354990: Improve negative tests coverage for jpackage signing
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Apr 2025 00:14:17 GMT, Alexey Semenyuk  wrote:

>> Add tests for the following test cases:
>>  - Expired certificate specified for signing;
>>  - Multiple certificates with the same name in one keychain.
>> 
>> Adding the new tests revealed an issue with MacCertificate - [JDK-8354989](https://bugs.openjdk.org/browse/JDK-8354989). This issue is also addressed in this PR.
>> 
>> Additionally:
>>  - Moved code to verify signatures in MacSignVerify class and reworked SigningBase verify functions to use MacSignVerify API.
>
> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix formatting
>  - Fix formatting

Marked as reviewed by almatvee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24762#pullrequestreview-2782457307

From almatvee at openjdk.org  Tue Apr 22 00:18:47 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 22 Apr 2025 00:18:47 GMT
Subject: RFR: 8354990: Improve negative tests coverage for jpackage signing
 [v2]
In-Reply-To: 
References: 
 
 <6UXfPj99bczO1OXsmZ1t7F8BwDtLtqOEgHeR4tv_pjY=.a48f7061-aca3-42ea-8f7a-a6f599a3f721@github.com>
 
Message-ID: 

On Tue, 22 Apr 2025 00:03:01 GMT, Alexey Semenyuk  wrote:

>> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSign.java line 410:
>> 
>>> 408:                         continue;
>>> 409:                     }
>>> 410:                     certs.add(cert);
>> 
>> Maybe:
>> 
>>                     try {
>>                         final X509Certificate cert = (X509Certificate)CERT_FACTORY.generateCertificate(in);
>>                         certs.add(cert);
>>                     } catch (Exception ex) {
>>                         TKit.trace("Failed to parse certificate data: " + ex);                        
>>                     }
>
> This will combine certificate creation and adding it to the list of certificates. If the latter fails, this is not a `Failed to parse certificate data` error.

I see. Agree.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24762#discussion_r2053136973

From asemenyuk at openjdk.org  Tue Apr 22 00:29:52 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 22 Apr 2025 00:29:52 GMT
Subject: Integrated: 8354990: Improve negative tests coverage for jpackage
 signing
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Apr 2025 21:11:35 GMT, Alexey Semenyuk  wrote:

> Add tests for the following test cases:
>  - Expired certificate specified for signing;
>  - Multiple certificates with the same name in one keychain.
> 
> Adding the new tests revealed an issue with MacCertificate - [JDK-8354989](https://bugs.openjdk.org/browse/JDK-8354989). This issue is also addressed in this PR.
> 
> Additionally:
>  - Moved code to verify signatures in MacSignVerify class and reworked SigningBase verify functions to use MacSignVerify API.

This pull request has now been integrated.

Changeset: 47f78a75
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/47f78a7529a2b290a07394e053bcfaff4907b7e5
Stats:     957 lines in 7 files changed: 716 ins; 134 del; 107 mod

8354990: Improve negative tests coverage for jpackage signing
8354989: Bug in MacCertificate class

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/24762

From duke at openjdk.org  Tue Apr 22 01:00:18 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 22 Apr 2025 01:00:18 GMT
Subject: RFR: 8077587: BigInteger Roots [v22]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'origin/BigInteger-nth-root' into BigInteger-nth-root
 - Merge branch 'BigInteger-nth-root' of https://github.com/fabioromano1/jdk into BigInteger-nth-root

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/8de6b825..100d0e14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=20-21

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From duke at openjdk.org  Tue Apr 22 01:07:41 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 22 Apr 2025 01:07:41 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Suggested change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/100d0e14..1942fd10

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=21-22

  Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From xgong at openjdk.org  Tue Apr 22 01:44:40 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 22 Apr 2025 01:44:40 GMT
Subject: RFR: 8351623: VectorAPI: Refactor subword gather load and add SVE
 implementation
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 20 Apr 2025 03:28:48 GMT, SendaoYan  wrote:

>> ### Summary:
>> [JDK-8318650](http://java-service.client.nvidia.com/?q=8318650) added the hotspot intrinsifying of subword gather load APIs for X86 platforms [1]. This patch aims at implementing the equivalent functionality for AArch64 SVE platform. In addition to the AArch64 backend support, this patch also refactors the API implementation in Java side and the compiler mid-end part to make the operations more efficient and maintainable across different architectures.
>> 
>> ### Background:
>> Vector gather load APIs load values from memory addresses calculated by adding a base pointer to integer indices stored in an int array. SVE provides native vector gather load instructions for byte/short types using an int vector saving indices (see [2][3]).
>> 
>> The number of loaded elements must match the index vector's element count. Since int elements are 4/2 times larger than byte/short elements, and given `MaxVectorSize` constraints, the operation may need to be splitted into multiple parts.
>> 
>> Using a 128-bit byte vector gather load as an example, there are four scenarios with different `MaxVectorSize`:
>> 
>> 1. `MaxVectorSize = 16, byte_vector_size = 16`:
>>    - Can load 4 indices per vector register
>>    - So can finish 4 bytes per gather-load operation
>>    - Requires 4 times of gather-loads and final merge
>>    Example:
>>    ```
>>    byte[] arr = [a, b, c, d, e, f, g, h, i, g, k, l, m, n, o, p, ...]
>>    int[] idx = [3, 2, 4, 1, 5, 7, 5, 2, 0, 6, 7, 1, 15, 10, 11, 9]
>> 
>>    4 gather-load:
>>    idx_v1 = [1 4 2 3]    gather_v1 = [0000 0000 0000 becd]
>>    idx_v2 = [2 5 7 5]    gather_v2 = [0000 0000 0000 cfhf]
>>    idx_v3 = [1 7 6 0]    gather_v3 = [0000 0000 0000 bhga]
>>    idx_v4 = [9 11 10 15] gather_v4 = [0000 0000 0000 jlkp]
>>    merge: v = [jlkp bhga cfhf becd]
>>    ```
>> 
>> 2. `MaxVectorSize = 32, byte_vector_size = MaxVectorSize / 2`:
>>    - Can load 8 indices per vector register
>>    - So can finish 8 bytes per gather-load operation
>>    - Requires 2 times of gather-loads and merge
>>    Example:
>>    ```
>>    byte[] arr = [a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, ...]
>>    int[] index = [3, 2, 4, 1, 5, 7, 5, 2, 0, 6, 7, 1, 15, 10, 11, 9]
>> 
>>    2 gather-load:
>>    idx_v1 = [2 5 7 5 1 4 2 3]
>>    idx_v2 = [9 11 10 15 1 7 6 0]
>>    gather_v1 = [0000 0000 0000 0000 0000 0000 cfhf becd]
>>    gather_v2 = [0000 0000 0000 0000 0000 0000 jlkp bhga]
>>    merge: v = [0000 0000 0000 0000 jlkp bhga cfhf becd]
>>    ```
>> 
>> 3. `MaxVectorSize = 64, byte_v...
>
> test/hotspot/jtreg/compiler/vectorapi/VectorGatherSubwordTest.java line 39:
> 
>> 37:  * @modules jdk.incubator.vector
>> 38:  *
>> 39:  * @run driver compiler.vectorapi.VectorGatherSubwordTest
> 
> Should we use `@run main` instead of `@run driver`

Thanks for taking a look at this PR! I think it's fine using `@run main` instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24679#discussion_r2053187161

From jpai at openjdk.org  Tue Apr 22 01:49:43 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 22 Apr 2025 01:49:43 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine [v6]
In-Reply-To: 
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
 
Message-ID: 

On Mon, 21 Apr 2025 17:42:33 GMT, Chen Liang  wrote:

>> When jdeps was migrated from old classfile to ClassFile API, the parsing semantic changed - error checks are now made lazily, and nested crashes from malformed signature or other problems is now latent, after a `ClassModel` instance is available. (The old error check existed only for constructing a `ClassModel`)
>> 
>> To address this issue, I have updated the way of iterating class files to be handler/consumer based like in the ClassFile API. This has the advantage that when one invocation of the handler fails of a `ClassFileError`, other invocations for other class files can proceed, and the exception handler has sufficient information to report a useful message indicating the source of error.
>> 
>> For the particular example of examining a proguard processed `dummy-scala.jar`, here is the new output of `jdeps dummy-scala.jar`:
>> 
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 59, expected an identifier: Lscala/collection/immutable/TreeMap$TreeMapBuilder.;: scala/collection/immutable/TreeMap$TreeMapBuilder.class (dummy-scala.jar)
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 49, expected an identifier: Lscala/collection/parallel/mutable/ParArray.;: scala/collection/parallel/mutable/ParArray.class (dummy-scala.jar)
>> 
>> 
>> Now, jdeps shows the bad class files. Inspection into the files reveal that proguard incorrectly deleted the simple class names with trailing `$`, for example, the original signature of the broken ParArray was `Lscala/collection/parallel/mutable/ParArray.ParArrayIterator$;`, so the `ParArrayIterator$` part was incorrectly dropped by proguard.
>> 
>> Testing: langtools/tools/jdeps.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use simple file name due to windows directory separators

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24604#pullrequestreview-2782534687

From liach at openjdk.org  Tue Apr 22 03:32:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 03:32:56 GMT
Subject: RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine [v6]
In-Reply-To: 
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
 
Message-ID: <0_1Vt0jQz48Vni5l09FaSMoSpSLbxbZ5GTZ7d3kaVi0=.c2c80ab3-6419-49d3-9a6d-a24fa0f97a0c@github.com>

On Mon, 21 Apr 2025 17:42:33 GMT, Chen Liang  wrote:

>> When jdeps was migrated from old classfile to ClassFile API, the parsing semantic changed - error checks are now made lazily, and nested crashes from malformed signature or other problems is now latent, after a `ClassModel` instance is available. (The old error check existed only for constructing a `ClassModel`)
>> 
>> To address this issue, I have updated the way of iterating class files to be handler/consumer based like in the ClassFile API. This has the advantage that when one invocation of the handler fails of a `ClassFileError`, other invocations for other class files can proceed, and the exception handler has sufficient information to report a useful message indicating the source of error.
>> 
>> For the particular example of examining a proguard processed `dummy-scala.jar`, here is the new output of `jdeps dummy-scala.jar`:
>> 
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 59, expected an identifier: Lscala/collection/immutable/TreeMap$TreeMapBuilder.;: scala/collection/immutable/TreeMap$TreeMapBuilder.class (dummy-scala.jar)
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 49, expected an identifier: Lscala/collection/parallel/mutable/ParArray.;: scala/collection/parallel/mutable/ParArray.class (dummy-scala.jar)
>> 
>> 
>> Now, jdeps shows the bad class files. Inspection into the files reveal that proguard incorrectly deleted the simple class names with trailing `$`, for example, the original signature of the broken ParArray was `Lscala/collection/parallel/mutable/ParArray.ParArrayIterator$;`, so the `ParArrayIterator$` part was incorrectly dropped by proguard.
>> 
>> Testing: langtools/tools/jdeps.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use simple file name due to windows directory separators

Thanks for the reviews! Reran tier 1 tests which includes this jdeps test and now everything passes. No related failure in tier2.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24604#issuecomment-2819970755

From liach at openjdk.org  Tue Apr 22 03:32:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 03:32:57 GMT
Subject: Integrated: 8341608: jdeps in JDK 23 crashes when parsing signatures
 while jdeps in JDK 22 works fine
In-Reply-To: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
References: <6fda_jMovCPm8SRRCXgtBEpKelzCDBrn8KrH0fRRz_k=.011d5658-6218-4c17-93fe-a63a95df14c7@github.com>
Message-ID: 

On Fri, 11 Apr 2025 22:45:55 GMT, Chen Liang  wrote:

> When jdeps was migrated from old classfile to ClassFile API, the parsing semantic changed - error checks are now made lazily, and nested crashes from malformed signature or other problems is now latent, after a `ClassModel` instance is available. (The old error check existed only for constructing a `ClassModel`)
> 
> To address this issue, I have updated the way of iterating class files to be handler/consumer based like in the ClassFile API. This has the advantage that when one invocation of the handler fails of a `ClassFileError`, other invocations for other class files can proceed, and the exception handler has sufficient information to report a useful message indicating the source of error.
> 
> For the particular example of examining a proguard processed `dummy-scala.jar`, here is the new output of `jdeps dummy-scala.jar`:
> 
> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 59, expected an identifier: Lscala/collection/immutable/TreeMap$TreeMapBuilder.;: scala/collection/immutable/TreeMap$TreeMapBuilder.class (dummy-scala.jar)
> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 49, expected an identifier: Lscala/collection/parallel/mutable/ParArray.;: scala/collection/parallel/mutable/ParArray.class (dummy-scala.jar)
> 
> 
> Now, jdeps shows the bad class files. Inspection into the files reveal that proguard incorrectly deleted the simple class names with trailing `$`, for example, the original signature of the broken ParArray was `Lscala/collection/parallel/mutable/ParArray.ParArrayIterator$;`, so the `ParArrayIterator$` part was incorrectly dropped by proguard.
> 
> Testing: langtools/tools/jdeps.

This pull request has now been integrated.

Changeset: 0be3f163
Author:    Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/0be3f163ed12db305673928d97f975d6f6bb6b1c
Stats:     357 lines in 8 files changed: 201 ins; 116 del; 40 mod

8341608: jdeps in JDK 23 crashes when parsing signatures while jdeps in JDK 22 works fine

Reviewed-by: jpai, henryjen

-------------

PR: https://git.openjdk.org/jdk/pull/24604

From swen at openjdk.org  Tue Apr 22 03:42:06 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 22 Apr 2025 03:42:06 GMT
Subject: RFR: 8355240: Remove unused Import in StringUTF16
Message-ID: 

This PR is to remove unused imports after PR #16425

-------------

Commit messages:
 - remove unused import

Changes: https://git.openjdk.org/jdk/pull/24788/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24788&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355240
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24788.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24788/head:pull/24788

PR: https://git.openjdk.org/jdk/pull/24788

From ccheung at openjdk.org  Tue Apr 22 05:31:01 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 22 Apr 2025 05:31:01 GMT
Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking [v5]
In-Reply-To: 
References: 
Message-ID: 

> This RFE allows --add-opens to be specified for AOT cache creation. AOT cache can be used during production run with --add-opens option as long as the same set of options is used during assembly phase.
> 
> Passed tiers 1 - 4 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  trailing whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24695/files
  - new: https://git.openjdk.org/jdk/pull/24695/files/95f2e9c6..465261f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24695&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24695&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24695.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24695/head:pull/24695

PR: https://git.openjdk.org/jdk/pull/24695

From iklam at openjdk.org  Tue Apr 22 05:36:48 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Apr 2025 05:36:48 GMT
Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking [v5]
In-Reply-To: 
References: 
 
Message-ID: <2vWft9LAmJcBtH4RAdMIy3K3hNPVD9shPOwJKmM6zmU=.802c49a5-94b7-4d3c-96cc-a37cbd37db92@github.com>

On Tue, 22 Apr 2025 05:31:01 GMT, Calvin Cheung  wrote:

>> This RFE allows --add-opens to be specified for AOT cache creation. AOT cache can be used during production run with --add-opens option as long as the same set of options is used during assembly phase.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   trailing whitespace

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24695#pullrequestreview-2782806700

From alanb at openjdk.org  Tue Apr 22 06:11:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Apr 2025 06:11:48 GMT
Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking [v3]
In-Reply-To: <9ov8LzpXXaWjbX9tGNGgyHp5QZIrLateO1f40JxRdGY=.3a841ff1-10c8-466c-a1e0-fc5548a1076f@github.com>
References: 
 
 
 <9ov8LzpXXaWjbX9tGNGgyHp5QZIrLateO1f40JxRdGY=.3a841ff1-10c8-466c-a1e0-fc5548a1076f@github.com>
Message-ID: <1O58pXQPOMGmtljeeOfF3EbI0p8skMnf_Z_O_1iQeGU=.be25216a-cceb-42bf-822f-3fec1f645126@github.com>

On Mon, 21 Apr 2025 22:54:37 GMT, Calvin Cheung  wrote:

>> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 165:
>> 
>>> 163:             BootLoader.getUnnamedModule(); // trigger  of BootLoader.
>>> 164:             CDS.defineArchivedModules(ClassLoaders.platformClassLoader(), ClassLoaders.appClassLoader());
>>> 165:             boolean extraExportsOrOpens = addExtraExportsAndOpens(bootLayer);
>> 
>> (1) The returned value of `addExtraExportsAndOpens()` is not used. So I think this function can be changed to `void`, and all occurrences of the local variable `extraExportsOrOpens` can be removed.
>> 
>> (2) I traced the code paths that depend on the effects of `--add-opens` and `--add-exports`. It Looks like some of the effects are recorded in the `java.lang.Module$ReflectionData::export` table:
>> 
>> https://github.com/openjdk/jdk/blob/684d3b336e9cb31707d35e75f9b785e04e1fdbee/src/java.base/share/classes/java/lang/Module.java#L398C2-L412
>> 
>> 
>>         /**
>>          * A module (1st key) exports or opens a package to another module
>>          * (2nd key). The map value is a map of package name to a boolean
>>          * that indicates if the package is opened.
>>          */
>>         static final WeakPairMap> exports =
>>             new WeakPairMap<>();
>> 
>> 
>> This table is *not* stored as part of the `ArchivedBootLayer`, so we must re-initialize this table in the production run. @AlanBateman could you confirm that this is correct.
>> 
>> Eventually, we should enhance the `ArchivedBootLayer` to also include the tables in `Module$ReflectionData`. That will obviate the call to `addExtraExportsAndOpens()` and save a few bytecodes during start-up (but the overall impact would be small, so it's not critical in the current PR). Because these tables use WeakReference, we need to wait for [JDK-8354897](https://bugs.openjdk.org/browse/JDK-8354897).
>
> Fixed (1) above.

> (2) I traced the code paths that depend on the effects of `--add-opens` and `--add-exports`. It Looks like some of the effects are recorded in the `java.lang.Module$ReflectionData::export` table:
> 
> https://github.com/openjdk/jdk/blob/684d3b336e9cb31707d35e75f9b785e04e1fdbee/src/java.base/share/classes/java/lang/Module.java#L398C2-L412
> 
> ```
>         /**
>          * A module (1st key) exports or opens a package to another module
>          * (2nd key). The map value is a map of package name to a boolean
>          * that indicates if the package is opened.
>          */
>         static final WeakPairMap> exports =
>             new WeakPairMap<>();
> ```
> 
> This table is _not_ stored as part of the `ArchivedBootLayer`, so we must re-initialize this table in the production run. @AlanBateman could you confirm that this is correct.

In the changes for "JEP draft: Prepare final means final", this is changed significantly so that reflectively exporting or opening a package during startup will add to openPackages/exportedPackages. Once the VM is fully initialized then reflective change via the addExports/addOpens API make use of ReflectionData. So no ReflectionData or weak refs setup for --add-exports/--add-opens. We could potential separate this out in advance so that ReflectionData doesn't need to be re-initialized.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24695#discussion_r2053392827

From swen at openjdk.org  Tue Apr 22 07:16:24 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 22 Apr 2025 07:16:24 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v5]
In-Reply-To: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com>
References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com>
Message-ID: <-K1EGfNzgL9kaixYfKFJtXEcOXAEizWCfnwJKgPxLRw=.f3720727-4adf-41b9-805a-6b67fec75911@github.com>

> Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString and BigDecimal::toPlainString performance and reduce duplicate code

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:

 - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501
 - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
 - remove getChars(long, int, char[])
 - copyright
 - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
 - simplify and comments
 - simplify
 - simplify
 - code style
 - revert change
 - ... and 20 more: https://git.openjdk.org/jdk/compare/2f7806ff...a5a07ce7

-------------

Changes: https://git.openjdk.org/jdk/pull/23310/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23310&range=04
  Stats: 452 lines in 3 files changed: 239 ins; 119 del; 94 mod
  Patch: https://git.openjdk.org/jdk/pull/23310.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23310/head:pull/23310

PR: https://git.openjdk.org/jdk/pull/23310

From jpai at openjdk.org  Tue Apr 22 07:24:46 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 22 Apr 2025 07:24:46 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 20 Apr 2025 13:01:30 GMT, Jason Zaugg  wrote:

>> 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance
>
> Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright and remove part of comment

Thank you Jason, this looks good to me. It would be good to have Jan's review of the latest state of this PR before integrating.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24176#pullrequestreview-2783066639

From duke at openjdk.org  Tue Apr 22 07:33:14 2025
From: duke at openjdk.org (Daishi Tabata)
Date: Tue, 22 Apr 2025 07:33:14 GMT
Subject: RFR: 8355249: Remove the use of WMIC from the entire source code
Message-ID: 

After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI.

The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency.

Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file.
Note: In my environment, it worked correctly even without these options.

The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in:

- `environment.html`: `windows/system/os` section
- `process.html`: `[Process ID]/windows/native/info` section

**Testing:**
I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes.

-------------

Commit messages:
 - Use powershell instead of wmic

Changes: https://git.openjdk.org/jdk/pull/24791/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24791&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355249
  Stats: 32 lines in 4 files changed: 6 ins; 2 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/24791.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24791/head:pull/24791

PR: https://git.openjdk.org/jdk/pull/24791

From jpai at openjdk.org  Tue Apr 22 07:40:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 22 Apr 2025 07:40:55 GMT
Subject: RFR: 8354898: jdk/internal/loader/NativeLibraries/Main.java fails
 on static JDK
In-Reply-To: 
References: 
Message-ID: <68U_vj5WY81keMaVqgpGwGWjvOEfBhIcR1kpf_noOgk=.49e2b7b2-9a0c-4187-b702-cf3cb5b1255d@github.com>

On Wed, 16 Apr 2025 23:41:40 GMT, Jiangli Zhou  wrote:

> Please review this simple test change that skips the test case loading using JDK `libzip.so` on static JDK in test/jdk/jdk/internal/loader/NativeLibraries/Main.java. AFAICT, the test case using `NativeLibrariesTest.LIB_NAME` (`libnativeLibrariesTest.so`) can provide coverage on static JDK.
> 
> Thanks

Hello Jiangli, can you add a few more details to the linked JBS issue? If I understand this change correctly, then what's being proposed in this PR seems to indicate that the `jdk.internal.loader.RawNativeLibraries` is unable to load `libzip` whose `Path` is determined by a call to the `System.mapLibraryName(...)` standard API. I don't currently have access to a static JDK. Can you include the `Path` that's returned for `System.mapLibraryName("zip")` on a static JDK?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24704#issuecomment-2820424514

From duke at openjdk.org  Tue Apr 22 07:41:43 2025
From: duke at openjdk.org (Daishi Tabata)
Date: Tue, 22 Apr 2025 07:41:43 GMT
Subject: RFR: 8355249: Remove the use of WMIC from the entire source code
 [v2]
In-Reply-To: 
References: 
Message-ID: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com>

> After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI.
> 
> The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency.
> 
> Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file.
> Note: In my environment, it worked correctly even without these options.
> 
> The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in:
> 
> - `environment.html`: `windows/system/os` section
> - `process.html`: `[Process ID]/windows/native/info` section
> 
> **Testing:**
> I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes.

Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision:

  run jcheck

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24791/files
  - new: https://git.openjdk.org/jdk/pull/24791/files/36e466d2..76a3a7ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24791&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24791&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24791.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24791/head:pull/24791

PR: https://git.openjdk.org/jdk/pull/24791

From vklang at openjdk.org  Tue Apr 22 08:07:55 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 22 Apr 2025 08:07:55 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v2]
In-Reply-To: 
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 
Message-ID: <6iGkzxPk3SpjQkYebGfrlU5bMM8k8UuHtkSiaoh_5qc=.50de17d4-238a-4374-a59d-dbe915af3e28@github.com>

On Fri, 18 Apr 2025 18:25:54 GMT, Chen Liang  wrote:

>> Perf numbers for simple main:
>> Linking of `Class::forName0` down from ~152 to ~83
>> 
>> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
>> JNI: ~45
>> baseline panama: ~164
>> patch: ~103
>> 
>> Also see #24705.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify FFM linker warmup

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 78:

> 76:         @Override
> 77:         public boolean equals(Object obj) {
> 78:             return obj instanceof LinkRequest other &&

Might be worth checking `obj == this || obj instanceof ...`

src/java.base/share/classes/jdk/internal/foreign/abi/LinkerOptions.java line 149:

> 147:         @Override
> 148:         public boolean equals(Object obj) {
> 149:             return obj instanceof FirstVariadicArg that && index == that.index;

Might be worth checking `obj == this || obj instanceof ...`

src/java.base/share/classes/jdk/internal/foreign/abi/NativeEntryPoint.java line 56:

> 54:         public boolean equals(Object o) {
> 55:             if (!(o instanceof CacheKey other)) return false;
> 56: 

Might be worth checking `o == this`

src/java.base/share/classes/jdk/internal/foreign/abi/VMStorage.java line 55:

> 53:     @Override
> 54:     public boolean equals(Object obj) {
> 55:         return obj instanceof VMStorage that &&

Might be worth checking `obj == this || obj instanceof ...`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2053566427
PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2053566702
PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2053569651
PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2053568877

From asotona at openjdk.org  Tue Apr 22 08:08:01 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 22 Apr 2025 08:08:01 GMT
Subject: RFR: 8354899: Reduce overhead associated with type switches
In-Reply-To: 
References: 
Message-ID: 

On Thu, 17 Apr 2025 00:08:55 GMT, Chen Liang  wrote:

> The downcallHandle method in Linker has a complex implementation, and type switches is triggered in multiple places in that handle.
> 
> After bytestacks analysis of a simple program that links the native implementation of Class::forName0, it turns out that:
> 1. there are a few missed usages of type switch in ClassFile API
> 2. type switch can speed up generation by using explicit stack maps, as stack map gen is over 50% of the generation instructions because the switch is branch-heavy, but the frames are actually simple.
> 
> These two combined are not that significant in the overall overhead of downcallHandle, but would be helpful for other workloads.

Both parts of this PR look good to me, however they seem to be unrelated.
I would suggest to create another PR for #1, as the Class-File API JDK boot safety is not related to the SUBJ.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24705#issuecomment-2820507514

From alanb at openjdk.org  Tue Apr 22 08:16:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Apr 2025 08:16:55 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 01:03:01 GMT, Jan Lahoda  wrote:

>> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
>> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
>> - `java. ... .IO` is no longer automatically imported in any compilation unit
>> - the feature is finalized (i.e. no longer requires `--enable-preview`)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add clause about handling of malformed/unmappable bytes.

src/java.base/share/classes/java/lang/IO.java line 41:

> 39:  * The {@link #readln()} and {@link #readln(String)} methods decode bytes read from
> 40:  * {@code System.in} into characters. The charset used for decoding is specified by the
> 41:  * {@link System#getProperties stdin.encoding} property. If this property is not present,

@stuart-marks Are you planning to propose/integrate pull/24738 in advance of the JEP update? Asking because this paragraph will need to be adjusted if pull/24738 doesn't go in first.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2053585828

From pminborg at openjdk.org  Tue Apr 22 08:26:17 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 08:26:17 GMT
Subject: RFR: 8354300: Mark String.hash field @Stable [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and `j.l.String.hashIsZero`. This means the VM can trust these fields to never change which enables constant folding optimizations.
> 
> This PR is tested in tier1, tier2, tier3, and tier4 which all pass.

Per Minborg 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 @Stable annotation from hashIsZero, add benchmark
 - Merge branch 'master' into string-stable-fields
 - Update copyright year
 - Annotate fields with @Stable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24625/files
  - new: https://git.openjdk.org/jdk/pull/24625/files/04184d06..89cc60ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24625&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24625&range=00-01

  Stats: 196452 lines in 612 files changed: 26247 ins; 168588 del; 1617 mod
  Patch: https://git.openjdk.org/jdk/pull/24625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24625/head:pull/24625

PR: https://git.openjdk.org/jdk/pull/24625

From mli at openjdk.org  Tue Apr 22 08:34:51 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 22 Apr 2025 08:34:51 GMT
Subject: Integrated: 8352504: RISC-V: implement and enable CMoveI/L
In-Reply-To: 
References: 
Message-ID: 

On Mon, 7 Apr 2025 14:23:52 GMT, Hamlin Li  wrote:

> Hi,
> Can you help to review this patch?
> On riscv, CMoveI/L already were implemented, but there are some gap:
> 1. CMoveI/L does not support comparison with float/double, corresponding tests are not turn on either.
> 2. Some optimization of C2 is not turned on, e.g. `Phi -> CMove -> min_max`.
> 3. lack of some corresponding performance tests.
> 
> Also there are some issue with current Zicond:
> 1. UseZicond is turned on automatically by hwprobe, but jmh tests show that it's not always bring benefit, in some situation it even brings regression, the reason is the generated code by Zicond is much larger than branch version, in particular when it's in a loop and unrolled.
> 
> This patch on riscv is to:
> 1. add CMoveI/L comparing float/double, and corresponding tests,
> 2. enable more C2 optimization,
> 3. add more benchmark tests,
> 4. turn off UseZicond by default.
> 
> Thanks!
> 
> ## Performance
> 
> ### MinMax
> test data
> 
> Benchmark | Mode | Cnt | Score - master | Score - master+UseZbb | Score - -master+UseZicond | Score - master+UseZicond+UseZbb | Score - cmovei | Score - cmovei+UseZbb | Score - cmovei+UseZicond | Score - cmovei+UseZicond+UseZbb | Error | Units | Opt (master/cmovei)
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> o.o.b.vm.compiler.IfMinMax.testReductionInt | avgt | 40 | 17152.075 | 17216.592 | 17272.493 | 17296.89 | 17127.844 | 17036.605 | 17299.333 | 17250.566 | 73.179 | ns/op | 1.001
> o.o.b.vm.compiler.IfMinMax.testReductionLong | avgt | 40 | 19770.828 | 19967.578 | 20268.905 | 20166.165 | 20065.552 | 20059.095 | 20161.914 | 20151.295 | 131.428 | ns/op | 0.985
> o.o.b.vm.compiler.IfMinMax.testSingleInt | avgt | 40 | 114.734 | 114.402 | 114.887 | 114.384 | 114.4 | 110.631 | 112.162 | 110.915 | 0.333 | ns/op | 1.003
> o.o.b.vm.compiler.IfMinMax.testSingleLong | avgt | 40 | 121.53 | 121.711 | 120.91 | 121.665 | 121.309 | 120.57 | 118.639 | 119.373 | 0.451 | ns/op | 1.002
> o.o.b.vm.compiler.IfMinMax.testVectorInt | avgt | 40 | 60130.165 | 60062.303 | 61839.776 | 61895.194 | 15887.398 | 15924.502 | 15874.835 | 15667.936 | 101.94 | ns/op | 3.785
> o.o.b.vm.compiler.IfMinMax.testVectorLong | avgt | 40 | 63855.379 | 6309...

This pull request has now been integrated.

Changeset: bcc33d5e
Author:    Hamlin Li 
URL:       https://git.openjdk.org/jdk/commit/bcc33d5ef3bdbfaee51c45014851c54028da03f1
Stats:     954 lines in 20 files changed: 905 ins; 14 del; 35 mod

8352504: RISC-V: implement and enable CMoveI/L
8346786: RISC-V: Reconsider ConditionalMoveLimit when adding conditional move

Reviewed-by: fyang, fjiang

-------------

PR: https://git.openjdk.org/jdk/pull/24490

From alanb at openjdk.org  Tue Apr 22 08:37:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Apr 2025 08:37:53 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 01:03:01 GMT, Jan Lahoda  wrote:

>> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
>> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
>> - `java. ... .IO` is no longer automatically imported in any compilation unit
>> - the feature is finalized (i.e. no longer requires `--enable-preview`)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add clause about handling of malformed/unmappable bytes.

src/java.base/share/classes/java/io/Console.java line 151:

> 149:     }
> 150: 
> 151:     /**

The copyright header will need to be updated on the changes to java.base as they seem to be first update to these sources in 2025.

src/java.base/share/classes/jdk/internal/misc/MethodFinder.java line 89:

> 87:         if (mainMethod == null) {
> 88:             //if not public method, try to lookup a non-public one
> 89:             mainMethod = JLA.findMethod(cls, false, "main", String[].class);

Is there a reason why the first findMethod can't use publicOnly=false?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2053622213
PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2053620975

From hgreule at openjdk.org  Tue Apr 22 08:50:47 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Tue, 22 Apr 2025 08:50:47 GMT
Subject: RFR: 8354300: Mark String.hash field @Stable [v2]
In-Reply-To: 
References: 
 
Message-ID: <7mTg1_cK9pOYOAwRiGCYzEoNFvhn-_rXlgHol55VAS8=.13ab626b-3c2b-4073-b382-146e9e5a9aa2@github.com>

On Tue, 22 Apr 2025 08:26:17 GMT, Per Minborg  wrote:

>> This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and `j.l.String.hashIsZero`. This means the VM can trust these fields to never change which enables constant folding optimizations.
>> 
>> This PR is tested in tier1, tier2, tier3, and tier4 which all pass.
>
> Per Minborg 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 @Stable annotation from hashIsZero, add benchmark
>  - Merge branch 'master' into string-stable-fields
>  - Update copyright year
>  - Annotate fields with @Stable

Would it make sense to have IR tests for this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24625#issuecomment-2820615223

From jpai at openjdk.org  Tue Apr 22 09:11:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 22 Apr 2025 09:11:56 GMT
Subject: RFR: 8355278: Improve debuggability of
 com/sun/jndi/ldap/LdapPoolTimeoutTest.java test
Message-ID: 

Can I please get a review of this test only change which proposes to improve the debuggability of `com/sun/jndi/ldap/LdapPoolTimeoutTest.java`?

This test has been failing intermittently in our CI for several years. Detailed are noted in https://bugs.openjdk.org/browse/JDK-8287062. Most of these failures are because the exception message, in an exception that was raised, contains an unexpected value (apparently `null`). The test doesn't propagate the unexpected exception, thus it's not clear why the exception message is different than what the test expects. The commit in this PR propagates the original exception if the message is unexpected. This should help identify the underlying cause of the test failure, if/when it fails the next time.

I have run this test with these changes and the test continues to pass.

-------------

Commit messages:
 - 8355278: Improve debuggability of com/sun/jndi/ldap/LdapPoolTimeoutTest.java test

Changes: https://git.openjdk.org/jdk/pull/24793/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24793&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355278
  Stats: 25 lines in 1 file changed: 14 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/24793.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24793/head:pull/24793

PR: https://git.openjdk.org/jdk/pull/24793

From pminborg at openjdk.org  Tue Apr 22 09:32:38 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 09:32:38 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v57]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/StableValue.java
  
  Co-authored-by: Viktor Klang 

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/cd654b2f..b68f77af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=56
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=55-56

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From pminborg at openjdk.org  Tue Apr 22 09:43:06 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 09:43:06 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v56]
In-Reply-To: <5Fch16i4tli5STNrBlXneMqNpq5z6JhKuHNhBbf73Qg=.2c76fc01-e702-4615-b39a-64f16be89879@github.com>
References: 
 
 <5Fch16i4tli5STNrBlXneMqNpq5z6JhKuHNhBbf73Qg=.2c76fc01-e702-4615-b39a-64f16be89879@github.com>
Message-ID: 

On Thu, 17 Apr 2025 09:24:13 GMT, Viktor Klang  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address comments on original vs underlying
>
> src/java.base/share/classes/java/lang/StableValue.java line 204:
> 
>> 202:  *         Set.of(1, 2, 4, 8, 16, 32);
>> 203:  *     private static final UnaryOperator UNDERLYING_LOG2 =
>> 204:  *         i -> 31 - Integer.numberOfLeadingZeros(i);
> 
> Would boxing be necessary?i.e. what would be needed to use java.util.function.IntUnaryOperator?

Boxing would be required in this example.  It would have been possible to provide a lambda that invoked an underlying `IntUnaryOperator`.


            private static final IntUnaryOperator LOG2_ORIGINAL =
                    i -> 31 - Integer.numberOfLeadingZeros(i);

            private static final Function LOG2_CACHED =
                    // @link substring="function" target="#function(Set,Function)" :
                    StableValue.function(CACHED_KEYS, LOG2_ORIGINAL::applyAsInt);


Writing a custom stable `IntUnaryOperator` is out of scope. At least in the first preview. I am planning on writing an article about that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2053750795

From pminborg at openjdk.org  Tue Apr 22 09:57:38 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 09:57:38 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v58]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with four additional commits since the last revision:

 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Viktor Klang 
 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Viktor Klang 
 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Viktor Klang 
 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Viktor Klang 

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/b68f77af..38956e6c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=57
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=56-57

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From pminborg at openjdk.org  Tue Apr 22 09:57:39 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 09:57:39 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v56]
In-Reply-To: <5Fch16i4tli5STNrBlXneMqNpq5z6JhKuHNhBbf73Qg=.2c76fc01-e702-4615-b39a-64f16be89879@github.com>
References: 
 
 <5Fch16i4tli5STNrBlXneMqNpq5z6JhKuHNhBbf73Qg=.2c76fc01-e702-4615-b39a-64f16be89879@github.com>
Message-ID: 

On Thu, 17 Apr 2025 10:51:14 GMT, Viktor Klang  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address comments on original vs underlying
>
> src/java.base/share/classes/java/lang/StableValue.java line 571:
> 
>> 569:      * thrown by the computing thread.
>> 570:      * 

>> 571:      * If the provided {@code underlying} supplier throws an exception, it is relayed
> 
> Suggestion:
> 
>      * If the provided {@code underlying} supplier throws an exception, it is rethrown

The term "relayed" is the same that is used in `Map`. Which is best?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2053774884

From pminborg at openjdk.org  Tue Apr 22 10:02:20 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 10:02:20 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v59]
In-Reply-To: 
References: 
Message-ID: <8a9A9US5ugcsXnUjMOmwBMEhHFgqNo4z6Oi3CsGgFOw=.44f96bff-a604-4911-b754-2eee1d5f9eb7@github.com>

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/StableValue.java
  
  Co-authored-by: Viktor Klang 

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/38956e6c..58a58ca3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=58
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=57-58

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From pminborg at openjdk.org  Tue Apr 22 10:11:55 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 10:11:55 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v60]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with five additional commits since the last revision:

 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Jorn Vernee 
 - Update test/jdk/java/lang/StableValue/StableMapTest.java
   
   Co-authored-by: Viktor Klang 
 - Update test/jdk/java/lang/StableValue/StableMapTest.java
   
   Co-authored-by: Viktor Klang 
 - Update test/jdk/java/lang/StableValue/StableMapTest.java
   
   Co-authored-by: Viktor Klang 
 - Update test/jdk/java/lang/StableValue/StableMapTest.java
   
   Co-authored-by: Viktor Klang 

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/58a58ca3..c3fabd68

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=59
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=58-59

  Stats: 16 lines in 2 files changed: 0 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From pminborg at openjdk.org  Tue Apr 22 10:15:29 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 10:15:29 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v61]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/StableValue.java
  
  Co-authored-by: Jorn Vernee 

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/c3fabd68..5952f9e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=60
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=59-60

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From jlahoda at openjdk.org  Tue Apr 22 10:17:54 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 22 Apr 2025 10:17:54 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 22 Apr 2025 08:34:36 GMT, Alan Bateman  wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add clause about handling of malformed/unmappable bytes.
>
> src/java.base/share/classes/jdk/internal/misc/MethodFinder.java line 89:
> 
>> 87:         if (mainMethod == null) {
>> 88:             //if not public method, try to lookup a non-public one
>> 89:             mainMethod = JLA.findMethod(cls, false, "main", String[].class);
> 
> Is there a reason why the first findMethod can't use publicOnly=false?

My reason was that when `publicOnly=false`, there's more classloading happening (unsurprisingly, as also the non-public methods must be resolved). Which may lead to a change of behavior if the traditional `public static main(String[])` exists.

IIRC there is a test relying on this behavior, but I don't have the name offhand. Will put it here when I have it.

For example:

$ cat Main.java 
public class Main {
    public static void main(String... args) {
        System.err.println("Hello!");
    }
    private Missing get() { return null; }
}
$ cat Missing.java 
public class Missing {
}
$ jdk-24/bin/javac Main.java Missing.java; rm Missing.class
$ jdk-24/bin/java -classpath . Main
Hello!
$ jdk-without-publicOnly=true/bin/java -classpath . Main
Error: Unable to initialize main class Main
Caused by: java.lang.NoClassDefFoundError: Missing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2053808119

From alanb at openjdk.org  Tue Apr 22 10:19:45 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Apr 2025 10:19:45 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v8]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
Message-ID: 

On Mon, 21 Apr 2025 20:47:38 GMT, Brian Burkhalter  wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8354724: Change "lines" to "characters" in spec of Reader.readAllChars, where appropriate

src/java.base/share/classes/java/io/Reader.java line 401:

> 399:      * Reads all remaining characters into a string.
> 400:      *
> 401:      * 
 This method reads all content including the line separators in

Again, just to say that it's all remaining rather than "all content" as some characters may have been consumed before this method is invoked.

Now that you have readAllChars, I think it would be good to prototype a readAllLines (or better name) on Reader too. Consuming all characters means that Reader should not need to take on the characteristics of a buffered-Reader.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2053810987

From pminborg at openjdk.org  Tue Apr 22 10:37:02 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 10:37:02 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v56]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 17 Apr 2025 16:25:21 GMT, Jorn Vernee  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address comments on original vs underlying
>
> src/java.base/share/classes/java/lang/StableValue.java line 126:
> 
>> 124:  * This property is crucial as evaluation of the supplier may have side effects,
>> 125:  * e.g., the call above to {@code Logger.create()} may result in storage resources
>> 126:  * being prepared.
> 
> I think it's better to avoid abbreviations like 'e.g.' in javadoc, and go for the full 'for example'.
> 
> Also, WRT the contents of this paragraph: if multiple threads execute the `orElseSet` statement concurrently, multiple different `Supplier` instances might be created and passed to `orElseSet`. I think the method guarantees that only one of these (multiple) suppliers will be evaluated. But, technically, there is no 'the supplier', I suppose.

I've changed the text to cover the case where one or several suppliers are provided.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2053838293

From pminborg at openjdk.org  Tue Apr 22 10:44:42 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 10:44:42 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v62]
In-Reply-To: 
References: 
Message-ID: <50-kKNIEp3V10GFTjaUbrtz-hey2TQvttB3JiosRwzo=.a0569fa1-e2a9-42d1-84c1-3e982a372844@github.com>

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Jorn Vernee 
 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Jorn Vernee 

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/5952f9e6..db700805

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=61
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=60-61

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From myankelevich at openjdk.org  Tue Apr 22 10:46:51 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 22 Apr 2025 10:46:51 GMT
Subject: RFR: 8355278: Improve debuggability of
 com/sun/jndi/ldap/LdapPoolTimeoutTest.java test
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Apr 2025 09:05:09 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this test only change which proposes to improve the debuggability of `com/sun/jndi/ldap/LdapPoolTimeoutTest.java`?
> 
> This test has been failing intermittently in our CI for several years. Detailed are noted in https://bugs.openjdk.org/browse/JDK-8287062. Most of these failures are because the exception message, in an exception that was raised, contains an unexpected value (apparently `null`). The test doesn't propagate the unexpected exception, thus it's not clear why the exception message is different than what the test expects. The commit in this PR propagates the original exception if the message is unexpected. This should help identify the underlying cause of the test failure, if/when it fails the next time.
> 
> I have run this test with these changes and the test continues to pass.

test/jdk/com/sun/jndi/ldap/LdapPoolTimeoutTest.java line 109:

> 107:             } catch (ExecutionException e) {
> 108:                 failedCount++;
> 109:                 System.err.println("test failure:");

Do you think giving each test failure a number or at least printing the `failedCount` might be beneficial for debugging? This way it would be easier to know if the error is happening exclusively on the first/ after the first/ last run. 
So the message in the `System.err` looked something like this:

Run 2 - failure 1 - error: 


-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24793#discussion_r2053852087

From pminborg at openjdk.org  Tue Apr 22 10:48:10 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 10:48:10 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v56]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 18 Apr 2025 12:47:37 GMT, Jorn Vernee  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address comments on original vs underlying
>
> src/java.base/share/classes/java/lang/StableValue.java line 389:
> 
>> 387:  * successful invocation. Since stable functions and stable collections are built on top
>> 388:  * of {@linkplain StableValue#orElseSet(Supplier) orElseSet()} they too are
>> 389:  * thread safe and guarantee at-most-once-per-input invocation.
> 
> I think you should drop the note here about stable collections being built on top of `orElseSet`. This is an interesting implementation detail, but not directly relevant for the specification, and some that we might want to change in the future.
> 
> I suggest just specifying the behavior of stable collections directly, without mentioning how they are implemented.

Good catch. I now say "Since stable functions and stable collections are built on top
of the same principles as {@linkplain StableValue#orElseSet(Supplier) orElseSet()} they
too are thread safe and guarantee at-most-once-per-input invocation."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2053853385

From myankelevich at openjdk.org  Tue Apr 22 10:49:56 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 22 Apr 2025 10:49:56 GMT
Subject: RFR: 8355278: Improve debuggability of
 com/sun/jndi/ldap/LdapPoolTimeoutTest.java test
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Apr 2025 09:05:09 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this test only change which proposes to improve the debuggability of `com/sun/jndi/ldap/LdapPoolTimeoutTest.java`?
> 
> This test has been failing intermittently in our CI for several years. Detailed are noted in https://bugs.openjdk.org/browse/JDK-8287062. Most of these failures are because the exception message, in an exception that was raised, contains an unexpected value (apparently `null`). The test doesn't propagate the unexpected exception, thus it's not clear why the exception message is different than what the test expects. The commit in this PR propagates the original exception if the message is unexpected. This should help identify the underlying cause of the test failure, if/when it fails the next time.
> 
> I have run this test with these changes and the test continues to pass.

Also, this is a nitpick, but still. There are quite a few unused imports in the file. Could you please remove them? :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24793#issuecomment-2820927318

From pminborg at openjdk.org  Tue Apr 22 11:03:35 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 11:03:35 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v63]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/StableValue.java
  
  Co-authored-by: Jorn Vernee 

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/db700805..828cae77

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=62
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=61-62

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From jpai at openjdk.org  Tue Apr 22 11:08:15 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 22 Apr 2025 11:08:15 GMT
Subject: RFR: 8355278: Improve debuggability of
 com/sun/jndi/ldap/LdapPoolTimeoutTest.java test
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Apr 2025 10:47:06 GMT, Mikhail Yankelevich  wrote:

> There are quite a few unused imports in the file. Could you please remove them? :)

Good catch. I've now removed those unused imports.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24793#issuecomment-2820970466

From jpai at openjdk.org  Tue Apr 22 11:08:15 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 22 Apr 2025 11:08:15 GMT
Subject: RFR: 8355278: Improve debuggability of
 com/sun/jndi/ldap/LdapPoolTimeoutTest.java test [v2]
In-Reply-To: 
References: 
Message-ID: 

> Can I please get a review of this test only change which proposes to improve the debuggability of `com/sun/jndi/ldap/LdapPoolTimeoutTest.java`?
> 
> This test has been failing intermittently in our CI for several years. Detailed are noted in https://bugs.openjdk.org/browse/JDK-8287062. Most of these failures are because the exception message, in an exception that was raised, contains an unexpected value (apparently `null`). The test doesn't propagate the unexpected exception, thus it's not clear why the exception message is different than what the test expects. The commit in this PR propagates the original exception if the message is unexpected. This should help identify the underlying cause of the test failure, if/when it fails the next time.
> 
> I have run this test with these changes and the test continues to pass.

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - Mikhail's review - print the task number that failed
 - remove unused imports from the test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24793/files
  - new: https://git.openjdk.org/jdk/pull/24793/files/dd6228e9..cc0b58f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24793&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24793&range=00-01

  Stats: 10 lines in 1 file changed: 0 ins; 7 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24793.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24793/head:pull/24793

PR: https://git.openjdk.org/jdk/pull/24793

From jpai at openjdk.org  Tue Apr 22 11:08:15 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 22 Apr 2025 11:08:15 GMT
Subject: RFR: 8355278: Improve debuggability of
 com/sun/jndi/ldap/LdapPoolTimeoutTest.java test [v2]
In-Reply-To: 
References: 
 
Message-ID: <7uTu4cFELF-MGPKZZ3gnpdrlr_xF3QAxLeu8r8ZJ_I4=.491e4a5a-86e5-4800-a5e8-20bc6a49117e@github.com>

On Tue, 22 Apr 2025 10:43:45 GMT, Mikhail Yankelevich  wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Mikhail's review - print the task number that failed
>>  - remove unused imports from the test
>
> test/jdk/com/sun/jndi/ldap/LdapPoolTimeoutTest.java line 109:
> 
>> 107:             } catch (ExecutionException e) {
>> 108:                 failedCount++;
>> 109:                 System.err.println("test failure:");
> 
> Do you think giving each test failure a number or at least printing the `failedCount` might be beneficial for debugging? This way it would be easier to know if the error is happening exclusively on the first/ after the first/ last run. 
> So the message in the `System.err` looked something like this:
> 
> Run 2 - failure 1 - error: 
> 

Hello Mikhail, that's a good point to print the task number that failed. I've now updated the PR to include that detail in the `System.err` message.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24793#discussion_r2053882350

From alan.bateman at oracle.com  Tue Apr 22 11:09:30 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 22 Apr 2025 12:09:30 +0100
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: <4d239bc7086c49f6b56f9b3c741f13c6@amazon.com>
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 
 
 <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
 
 <3f1c69a7ac5946809d2af850d7d59db9@amazon.com>
 
 
 
 <4741eceb3beb40c2bc82613c67836d66@amazon.com>
 
 
 
 <4c4aac5737d844a4959885c65f17efee@amazon.com>
 <0249c80513c74209b34b63cce0f7a2c8@amazon.com>
 <4d239bc7086c49f6b56f9b3c741f13c6@amazon.com>
Message-ID: 

On 21/04/2025 17:46, Engebretson, John wrote:
>
> Following up on MemoryOutputStream, etc. ? the conversation has 
> considered a few alternatives:
>
>
> 1. Hide the new class behind ByteArrayOutputStream.unsynchronized()
>
> 2. Create a new public class providing views to OutputStream, Channel, 
> InputStream
>
> 3. Something to do with an Object[] variant
>
> ? I would personally reject any code review that used 
> ?unsynchronized()? to describe this class, since that is only a minor 
> property of the change.? I could live with ?scalable? or something 
> along those lines.
>
> ? A new public class provides more capabilities than I initially 
> proposed, but of course requires a new public class. ?
>
> ? The Object[] variant is interesting but I have no pressing need for 
> it.? This probably gets a pin in it unless someone provides a use case.
>
>

Maybe the two efforts should be separated.

The removal of biased locking has shinned light on the synchronization 
in BAIS/BAOS. It's been there since JDK 1.0 and too risky to change. We 
need to decide whether to specify this long standing behavior. We also 
need to explore adding a factory method to both to obtain a stream that 
isn't thread safe. The factory methods can return a different 
implementation, in particular BAOS.unsynchronized (or whatever name it 
gets) does not need to collect the bytes in a contiguous array. So 
having a BAOS.unsynchronized may help with some of the scenarios that 
you are looking at.

I think the PR proposing MemoryOutputStream is a bit premature and it 
will take a bit more work, and prototypes, to get a handle on the 
problem and help inform if a standard API makes sense. A sink that can 
collect an unbounded number of bytes could be fun to try to optimize for 
different usages. What isn't clear from the exploration so far is how to 
interface to other APIs. A method to return a byte[], like 
BAOS::toByteArray, is problematic when the number of bytes don't fit in 
an int. Maybe you have explored a segment like API or a cursor or 
consumer API to handle the bytes?

-Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pminborg at openjdk.org  Tue Apr 22 11:11:58 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 11:11:58 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v64]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with four additional commits since the last revision:

 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Jorn Vernee 
 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Jorn Vernee 
 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Jorn Vernee 
 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Jorn Vernee 

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/828cae77..68e2aebf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=63
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=62-63

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From pminborg at openjdk.org  Tue Apr 22 11:15:05 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 11:15:05 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v56]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 18 Apr 2025 13:47:04 GMT, Jorn Vernee  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address comments on original vs underlying
>
> src/java.base/share/classes/java/lang/StableValue.java line 651:
> 
>> 649:      * @param         the type of results delivered by the returned Function
>> 650:      * @throws NullPointerException if the provided set of {@code inputs} contains a
>> 651:      *                              {@code null} element.
> 
> This doesn't seem to be checked by this method.

I will add a comment that says where the null checks are made.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2053894060

From pminborg at openjdk.org  Tue Apr 22 11:28:27 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 11:28:27 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v65]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/util/ImmutableCollections.java
  
  Co-authored-by: Jorn Vernee 

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/68e2aebf..f97235f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=64
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=63-64

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From pminborg at openjdk.org  Tue Apr 22 11:28:28 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 11:28:28 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v56]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 18 Apr 2025 14:30:51 GMT, Jorn Vernee  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address comments on original vs underlying
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 1592:
> 
>> 1590:                     final K k = inner.getKey();
>> 1591:                     return new NullableKeyValueHolder<>(k, inner.getValue().orElseSet(new Supplier() {
>> 1592:                         @Override public V get() { return mapper.apply(k); }}));
> 
> I suppose you could potentially make this more lazy by returning an `Entry` implementation that only evaluates the mapper when calling `Entry::getValue`.

Yepp. Interesting idea.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2053909004

From pminborg at openjdk.org  Tue Apr 22 11:37:02 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 11:37:02 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v56]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 18 Apr 2025 14:43:19 GMT, Jorn Vernee  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address comments on original vs underlying
>
> src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 111:
> 
>> 109:             min = Math.min(min, ordinal);
>> 110:             max = Math.max(max, ordinal);
>> 111:             bitSet.set(ordinal);
> 
> This doesn't look right wrt the way the bitset is initialized. `ordinal` can be larger than `inputs.size()`. For example for `enum X { A, B, C }` where the key set is `{ C }`.

Good catch!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2053926778

From pminborg at openjdk.org  Tue Apr 22 11:57:26 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 11:57:26 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v66]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java
  
  Co-authored-by: Jorn Vernee 

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/f97235f9..444188af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=65
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=64-65

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From rgiulietti at openjdk.org  Tue Apr 22 12:00:42 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 22 Apr 2025 12:00:42 GMT
Subject: RFR: 8355240: Remove unused Import in StringUTF16
In-Reply-To: 
References: 
Message-ID: <_i7Ds4SkxEy2GdmQ1QXkWQLA7bsd7QYIGy91JRkdaCU=.927d73e3-5c0a-4c91-ae38-a6e374c88f19@github.com>

On Tue, 22 Apr 2025 03:35:03 GMT, Shaojin Wen  wrote:

> This PR is to remove unused imports after PR #16425

Thanks

-------------

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24788#pullrequestreview-2783853888

From pminborg at openjdk.org  Tue Apr 22 12:04:21 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 12:04:21 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v67]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 355 commits:

 - Address comments in PR
 - Merge branch 'implement-jep502' of https://github.com/minborg/jdk into implement-jep502
 - Update src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java
   
   Co-authored-by: Jorn Vernee 
 - Update src/java.base/share/classes/java/util/ImmutableCollections.java
   
   Co-authored-by: Jorn Vernee 
 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Jorn Vernee 
 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Jorn Vernee 
 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Jorn Vernee 
 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Jorn Vernee 
 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Jorn Vernee 
 - Update src/java.base/share/classes/java/lang/StableValue.java
   
   Co-authored-by: Jorn Vernee 
 - ... and 345 more: https://git.openjdk.org/jdk/compare/2f7806ff...63f3d1c2

-------------

Changes: https://git.openjdk.org/jdk/pull/23972/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=66
  Stats: 4777 lines in 31 files changed: 4754 ins; 0 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From a.rameykov at gmail.com  Tue Apr 22 12:18:25 2025
From: a.rameykov at gmail.com (Anton Rameykov)
Date: Tue, 22 Apr 2025 15:18:25 +0300
Subject: The virtual thread is not parked in InetAddress isReachable
Message-ID: 

Good afternoon, everyone! I think I've found a bug. There is a code that
basically pings the server. I decided to test it on virtual threads and for
some reason they don't work in it.
Code:
```
    public static void main(String[] args) throws ExecutionException,
InterruptedException {
        System.out.println("Test fixed thread poll");
        long start = System.currentTimeMillis();
        var counter =
ping(Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors()));
        System.out.println("Execute time " + (System.currentTimeMillis() -
start) + " " + counter);

        System.out.println("half-time break");
        LockSupport.parkNanos(10000000000L);

        System.out.println("Test virtual thread poll");
        start = System.currentTimeMillis();
        counter = ping(Executors.newVirtualThreadPerTaskExecutor());
        System.out.println("Execute time " + (System.currentTimeMillis() -
start) + " " + counter);


    }

    private static int ping(ExecutorService executor) throws
ExecutionException, InterruptedException {
        AtomicInteger counter = new AtomicInteger();
        var futures = Stream.> builder();
        for (int i = 0; i < 1000; i++) {
            var fut = CompletableFuture.runAsync(() -> {
                try {
                    InetAddress address = InetAddress.getByName("8.8.8.8");
                    boolean reachable = address.isReachable(100);
                    counter.incrementAndGet();
                } catch (Throwable e) {
                    e.printStackTrace();
                }
            }, executor);
            futures.add(fut);
        }

CompletableFuture.allOf(futures.build().toArray(CompletableFuture[]::new)).get();
        return counter.get();
    }

```
I get the following results. (-Djdk.tracePinnedThreads=full is enabled and
it outputs nothing to the console)
Test fixed thread poll:
Execute time 6317 1000
Test virtual thread poll:
Execute time 6319 1000

I expected to get results like this. (You can get such results if you
replace the request to the network with Thread.sleep(100))
Test fixed thread poll:
Execute time 6308 1000
Test virtual thread poll:
Execute time 110 1000


openjdk 22.0.2 2024-07-16
OpenJDK Runtime Environment GraalVM CE 22.0.2+9.1 (build 22.0.2+9-jvmci-b01)
OpenJDK 64-Bit Server VM GraalVM CE 22.0.2+9.1 (build 22.0.2+9-jvmci-b01,
mixed mode, sharing)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Tue Apr 22 12:30:59 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 22 Apr 2025 12:30:59 GMT
Subject: RFR: 8077587: BigInteger Roots [v24]
In-Reply-To: 
References: 
Message-ID: <6ilA_XUBGVlRhyhNcqvFLPVjEkjJqDwjwe9b2hJt0hg=.24fe64e6-6a13-4df0-b33e-19ffe128b9ef@github.com>

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Delete useless folder

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/1942fd10..0e1a99e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=22-23

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From jlahoda at openjdk.org  Tue Apr 22 12:39:05 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 22 Apr 2025 12:39:05 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v5]
In-Reply-To: 
References: 
Message-ID: 

> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
> - `java. ... .IO` is no longer automatically imported in any compilation unit
> - the feature is finalized (i.e. no longer requires `--enable-preview`)

Jan Lahoda has updated the pull request incrementally with seven additional commits since the last revision:

 - Merge remote-tracking branch 'origin/finalize-concise-source-files' into finalize-concise-source-files
 - Reverting test commit.
   
   This reverts commit 7047cf007cc7de937aa21e96125083ee92932692.
 - Fixing tests.
 - Updating copyright year.
 - Adding bug number to tests.
 - Fixing IO tests path
 - Scratch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24438/files
  - new: https://git.openjdk.org/jdk/pull/24438/files/05cc336e..48399888

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=03-04

  Stats: 53 lines in 43 files changed: 3 ins; 0 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/24438.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24438/head:pull/24438

PR: https://git.openjdk.org/jdk/pull/24438

From jlahoda at openjdk.org  Tue Apr 22 12:39:06 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 22 Apr 2025 12:39:06 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 22 Apr 2025 08:35:20 GMT, Alan Bateman  wrote:

>> Jan Lahoda has updated the pull request incrementally with seven additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/finalize-concise-source-files' into finalize-concise-source-files
>>  - Reverting test commit.
>>    
>>    This reverts commit 7047cf007cc7de937aa21e96125083ee92932692.
>>  - Fixing tests.
>>  - Updating copyright year.
>>  - Adding bug number to tests.
>>  - Fixing IO tests path
>>  - Scratch
>
> src/java.base/share/classes/java/io/Console.java line 151:
> 
>> 149:     }
>> 150: 
>> 151:     /**
> 
> The copyright header will need to be updated on the changes to java.base as they seem to be first update to these sources in 2025.

Fixed here:
https://github.com/openjdk/jdk/pull/24438/commits/44fccf3ad9eeddb20b75bd2516da5358eb667926

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2054025498

From jlahoda at openjdk.org  Tue Apr 22 12:39:06 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 22 Apr 2025 12:39:06 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 7 Apr 2025 17:58:45 GMT, Naoto Sato  wrote:

>> Jan Lahoda has updated the pull request incrementally with seven additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/finalize-concise-source-files' into finalize-concise-source-files
>>  - Reverting test commit.
>>    
>>    This reverts commit 7047cf007cc7de937aa21e96125083ee92932692.
>>  - Fixing tests.
>>  - Updating copyright year.
>>  - Adding bug number to tests.
>>  - Fixing IO tests path
>>  - Scratch
>
> test/jdk/java/lang/IO/IO/IO.java line 1:
> 
>> 1: /*
> 
> Is there reason to create a test subdirectory `IO` under `java.lang.IO` package?

Sorry, I missed this comment. Fixed here:
https://github.com/openjdk/jdk/pull/24438/commits/bacc1a2aa0251cc099d667b3ad5628ca1fc33446

> test/jdk/java/lang/IO/IO/IO.java line 53:
> 
>> 51: /*
>> 52:  * @test
>> 53:  * @bug 8305457 8342936 8351435
> 
> Issue id needs to be added (and other test files too)

Sorry, I missed this comment. Fixed here:
https://github.com/openjdk/jdk/pull/24438/commits/5d02ff6f34e20374627d0ef0b31e9db4e1bf6f2b

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2054024689
PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2054025088

From pminborg at openjdk.org  Tue Apr 22 12:42:39 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 12:42:39 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v68]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Resolve merge problem

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/63f3d1c2..82f39246

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=67
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=66-67

  Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From jengebr at amazon.com  Tue Apr 22 12:52:04 2025
From: jengebr at amazon.com (Engebretson, John)
Date: Tue, 22 Apr 2025 12:52:04 +0000
Subject: JDK-8352891 Performance improvements to ByteArrayOutputStream
In-Reply-To: 
References: <8721e7784793451187c5b6099eb37756@amazon.com>
 <8d453b79099b4675bce7f3902e3cd74f@amazon.com>
 <10ac0b6f-5885-40c8-8bd2-ae374b7538c9@oracle.com>
 
 
 <1cdf778b84b14eeda1bd8ee2808c6e24@amazon.com>
 
 <3f1c69a7ac5946809d2af850d7d59db9@amazon.com>
 
 
 
 <4741eceb3beb40c2bc82613c67836d66@amazon.com>
 
 
 
 <4c4aac5737d844a4959885c65f17efee@amazon.com>
 <0249c80513c74209b34b63cce0f7a2c8@amazon.com>
 <4d239bc7086c49f6b56f9b3c741f13c6@amazon.com>
 
Message-ID: 

  Thank you Alan!  I?ll try to address each of your points, apologies if I miss anything:

        Maybe the two efforts should be separated.

  I?m good with that, and will operate that way unless someone argues otherwise.

       The factory methods can return a different implementation, in particular BAOS.unsynchronized (or whatever name it gets) does not need to collect the bytes in a contiguous array. So having a BAOS.unsynchronized may help with some of the scenarios that you are looking at.

  I think this is a clever way to go and I?m in favor? just not sold on the name.  I won?t abandon the effort if you feel otherwise.  ?  Let me know if we?re ready to proceed with this or another name.

      I think the PR proposing MemoryOutputStream is a bit premature

  This was intended solely to share code for discussion, and it?s been effective in that sense.  I agree that the PR is nowhere near merging.

      Maybe you have explored a segment like API or a cursor or consumer API to handle the bytes?

  The current version of the PR is along these lines, providing one public class whose contents are available via views (SeekableByteChannel, BAOS, ByteArrayInputStream) as well as the usual add/write/updates, long size(), and lambda-based applyToSegment(Function) and applyToIndex(Function).  The public wrapping needs to evolve but I think these provide the core of the API.
    John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From alan.bateman at oracle.com  Tue Apr 22 12:59:14 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 22 Apr 2025 13:59:14 +0100
Subject: The virtual thread is not parked in InetAddress isReachable
In-Reply-To: 
References: 
Message-ID: 

On 22/04/2025 13:18, Anton Rameykov wrote:
> :
> ? ? ? ? ? ? ? ? ? ? InetAddress address = 
> InetAddress.getByName("8.8.8.8");
> ? ? ? ? ? ? ? ? ? ? boolean reachable = address.isReachable(100);
cc'ing net-dev as that is where the networking code is maintained. Right 
now, the the IGMP and TCP implementations of isReachable are written in 
native code. These are good candidates to re-implement in Java and FFM. 
In particular, the TCP implementation (use when not root or permission 
to create raw sockets) could be migrated and should just park gracefully 
when waiting to see if a connection can be established.

-Alan

From jlahoda at openjdk.org  Tue Apr 22 13:11:45 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 22 Apr 2025 13:11:45 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 20 Apr 2025 13:01:30 GMT, Jason Zaugg  wrote:

>> 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance
>
> Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright and remove part of comment

Looks good to me.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24176#pullrequestreview-2784053530

From jlahoda at openjdk.org  Tue Apr 22 13:14:45 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 22 Apr 2025 13:14:45 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance [v3]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Thu, 27 Mar 2025 23:52:00 GMT, Jason Zaugg  wrote:

> Noting that I found `jarFsProvider` to be a useful extension point (albeit in undocumented API) for injecting performance improvements into existing `javac` versions (both the `zipinfo-time` change, and further changes to defer the `close` of `ZipFileSystem` over JARs known to be immutable).

I'll note this is not the correct approach. This is not only an undocumented API. This is an implementation detail, subject to change at any time for any reason. javac supports running with a custom `JavaFileManager`, which can provide caching implementations for any queries, as desired.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24176#discussion_r2054089055

From pminborg at openjdk.org  Tue Apr 22 13:15:21 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 13:15:21 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v69]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix build problem

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/82f39246..06585e62

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=68
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=67-68

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From a.rameykov at gmail.com  Tue Apr 22 13:28:29 2025
From: a.rameykov at gmail.com (Anton Rameykov)
Date: Tue, 22 Apr 2025 16:28:29 +0300
Subject: The virtual thread is not parked in InetAddress isReachable
In-Reply-To: 
References: 
 
Message-ID: 

Alan, good day to you. I have a few questions. Could you please advise me
to forward my initial message to the net-dev mailing list? Sorry, it's just
my first time with the mailing model. And second question, if the thread
went to native code why Djdk.tracePinnedThreads=full didn't work and didn't
show debugging information.

??, 22 ???. 2025??. ? 15:59, Alan Bateman :

> On 22/04/2025 13:18, Anton Rameykov wrote:
> > :
> >                     InetAddress address =
> > InetAddress.getByName("8.8.8.8");
> >                     boolean reachable = address.isReachable(100);
> cc'ing net-dev as that is where the networking code is maintained. Right
> now, the the IGMP and TCP implementations of isReachable are written in
> native code. These are good candidates to re-implement in Java and FFM.
> In particular, the TCP implementation (use when not root or permission
> to create raw sockets) could be migrated and should just park gracefully
> when waiting to see if a connection can be established.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pminborg at openjdk.org  Tue Apr 22 13:30:21 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 13:30:21 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v70]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix rawtype problem

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/06585e62..3f71da0c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=69
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=68-69

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From dfuchs at openjdk.org  Tue Apr 22 13:55:41 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 22 Apr 2025 13:55:41 GMT
Subject: RFR: 8354424: java/util/logging/LoggingDeadlock5.java fails
 intermittently in tier6 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 21 Apr 2025 19:05:54 GMT, Joe Darcy  wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removing test from the problem list.
>
> test/jdk/java/util/logging/LoggingDeadlock5.java line 127:
> 
>> 125:         // in higher tiers, so it's necessary to be a bit pessimistic here.
>> 126:         private final static Duration JOIN_WAIT =
>> 127:                 Duration.ofMillis(Utils.adjustTimeout(2000));
> 
> Just checking, adjustTimeout does scaling based on the timeout factor given to jtreg?
> 
> What happens to the expected test running time to the test in lower tiers without as high loads?

Hi Joe, yes `adjustTimeout` will scale based on the jtreg timeout factor. I believe the behaviour is to multiply whatever hardcoded timeout is passed by the timeout factor.
On lower tiers, in our CI, I beleive it means the test will have to wait for 8s before it can assert that a deadlock is detected. That should be way off the default jtreg timeout - which IIRC is 480s on lower tiers.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24687#discussion_r2054172951

From pminborg at openjdk.org  Tue Apr 22 13:56:54 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 13:56:54 GMT
Subject: Withdrawn: 8350075: Performance difference between SegmentAllocator
 methods
In-Reply-To: 
References: 
Message-ID: <2SoK07dbQTmF91zw5C6AqOenWFUv7RiKyouTWKbmzas=.c1515262-b27f-4eda-bc82-844524259cf0@github.com>

On Fri, 14 Feb 2025 09:19:35 GMT, Per Minborg  wrote:

> This PR proposes to add `@ForceInline` to the `default` methods in `SegmentAllocator` that do not already have it.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/23628

From swen at openjdk.org  Tue Apr 22 14:24:15 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 22 Apr 2025 14:24:15 GMT
Subject: RFR: 8355300: Add final to BitSieve
Message-ID: 

As the title says, adding final to fields that do not change and BitSieve that will not be inherited will make C2 optimization more friendly.

-------------

Commit messages:
 - final

Changes: https://git.openjdk.org/jdk/pull/24796/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24796&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355300
  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24796.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24796/head:pull/24796

PR: https://git.openjdk.org/jdk/pull/24796

From liach at openjdk.org  Tue Apr 22 14:24:16 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 14:24:16 GMT
Subject: RFR: 8355300: Add final to BitSieve
In-Reply-To: 
References: 
Message-ID: <1MB6IpUsBxR9XMw65U_N8uerdrtzzSwTHF_Csrc-jSA=.1b69a247-0abc-4feb-ad8e-883111caf294@github.com>

On Tue, 22 Apr 2025 11:10:46 GMT, Shaojin Wen  wrote:

> As the title says, adding final to fields that do not change and BitSieve that will not be inherited will make C2 optimization more friendly.

src/java.base/share/classes/java/math/BitSieve.java line 51:

> 49:      * Stores the bits in this bitSieve.
> 50:      */
> 51:     private final long bits[];

Suggestion:

    private final long[] bits;

We can do this too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24796#discussion_r2054212128

From swen at openjdk.org  Tue Apr 22 14:25:12 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 22 Apr 2025 14:25:12 GMT
Subject: RFR: 8355301: Simplify the code by using record
Message-ID: 

As the title says, this is a simple refactoring that simplifies the code by using record.

-------------

Commit messages:
 - Simplify the code using record

Changes: https://git.openjdk.org/jdk/pull/24795/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24795&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355301
  Stats: 20 lines in 1 file changed: 0 ins; 12 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/24795.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24795/head:pull/24795

PR: https://git.openjdk.org/jdk/pull/24795

From luhenry at openjdk.org  Tue Apr 22 14:48:48 2025
From: luhenry at openjdk.org (Ludovic Henry)
Date: Tue, 22 Apr 2025 14:48:48 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Apr 2025 18:03:47 GMT, Vladimir Ivanov  wrote:

>> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
>> 
>> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
>> 
>> The patch consists of the following parts:
>>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
>> 
>> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
>> 
>> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
>> 
>> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
>> 
>> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
>> 
>> Thanks!
>
> Vladimir Ivanov 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 24 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into vector.math.01.java
>  - RVV and SVE adjustments
>  - fix broken merge
>  - Merge branch 'master' into vector.math.01.java
>  - Fix debugName handling
>  - Merge branch 'master' into vector.math.01.java
>  - RVV and SVE adjustments
>  - Merge branch 'master' into vector.math.01.java
>  - Fix windows-aarch64 build failure
>  - features_string -> cpu_info_string
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/63ffaec1...88eacc48

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 75:

> 73:             return switch (StaticProperty.osArch()) {
> 74:                 case "amd64", "x86_64" -> SVML;
> 75:                 case "aarch64" -> SLEEF;

We should be supporting SLEEF on `riscv64`. Was there a specific motivation not to include it here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2054281193

From duke at openjdk.org  Tue Apr 22 14:56:20 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 22 Apr 2025 14:56:20 GMT
Subject: RFR: 8077587: BigInteger Roots [v25]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Optimized computation of nth root's remainder

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/0e1a99e8..9cd136cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=23-24

  Stats: 47 lines in 2 files changed: 15 ins; 12 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From liach at openjdk.org  Tue Apr 22 14:57:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 14:57:48 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v2]
In-Reply-To: <6iGkzxPk3SpjQkYebGfrlU5bMM8k8UuHtkSiaoh_5qc=.50de17d4-238a-4374-a59d-dbe915af3e28@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 
 <6iGkzxPk3SpjQkYebGfrlU5bMM8k8UuHtkSiaoh_5qc=.50de17d4-238a-4374-a59d-dbe915af3e28@github.com>
Message-ID: 

On Tue, 22 Apr 2025 08:03:19 GMT, Viktor Klang  wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify FFM linker warmup
>
> src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 78:
> 
>> 76:         @Override
>> 77:         public boolean equals(Object obj) {
>> 78:             return obj instanceof LinkRequest other &&
> 
> Might be worth checking `obj == this || obj instanceof ...`

No. We are always using `new LinkRequest` so this "fast path" will 100% miss.

> src/java.base/share/classes/jdk/internal/foreign/abi/NativeEntryPoint.java line 56:
> 
>> 54:         public boolean equals(Object o) {
>> 55:             if (!(o instanceof CacheKey other)) return false;
>> 56: 
> 
> Might be worth checking `o == this`

Always used with `new CacheKey` in `NativeEntryPoint.make`, no benefit too.

> src/java.base/share/classes/jdk/internal/foreign/abi/VMStorage.java line 55:
> 
>> 53:     @Override
>> 54:     public boolean equals(Object obj) {
>> 55:         return obj instanceof VMStorage that &&
> 
> Might be worth checking `obj == this || obj instanceof ...`

This one seems created each time when a particular downcall function shape is requested too; so no point of identity checks either.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2054294141
PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2054300716
PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2054299075

From liach at openjdk.org  Tue Apr 22 15:00:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 15:00:41 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v2]
In-Reply-To: <6iGkzxPk3SpjQkYebGfrlU5bMM8k8UuHtkSiaoh_5qc=.50de17d4-238a-4374-a59d-dbe915af3e28@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 
 <6iGkzxPk3SpjQkYebGfrlU5bMM8k8UuHtkSiaoh_5qc=.50de17d4-238a-4374-a59d-dbe915af3e28@github.com>
Message-ID: 

On Tue, 22 Apr 2025 08:03:30 GMT, Viktor Klang  wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify FFM linker warmup
>
> src/java.base/share/classes/jdk/internal/foreign/abi/LinkerOptions.java line 149:
> 
>> 147:         @Override
>> 148:         public boolean equals(Object obj) {
>> 149:             return obj instanceof FirstVariadicArg that && index == that.index;
> 
> Might be worth checking `obj == this || obj instanceof ...`

I think this is still unlikely to hit (it is possible if people intentionally reuse the value of a `Linker.Option.firstVariadicArg` call), most of the usages will see non-identity equality comparisons.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2054306216

From liach at openjdk.org  Tue Apr 22 15:02:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 15:02:46 GMT
Subject: RFR: 8354300: Mark String.hash field @Stable [v2]
In-Reply-To: <7mTg1_cK9pOYOAwRiGCYzEoNFvhn-_rXlgHol55VAS8=.13ab626b-3c2b-4073-b382-146e9e5a9aa2@github.com>
References: 
 
 <7mTg1_cK9pOYOAwRiGCYzEoNFvhn-_rXlgHol55VAS8=.13ab626b-3c2b-4073-b382-146e9e5a9aa2@github.com>
Message-ID: 

On Tue, 22 Apr 2025 08:47:39 GMT, Hannes Greule  wrote:

> Would it make sense to have IR tests for this?

We actually need a set of IR tests for core library APIs that are extremely performance sensitive with constant folding.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24625#issuecomment-2821621465

From liach at openjdk.org  Tue Apr 22 15:02:45 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 15:02:45 GMT
Subject: RFR: 8354300: Mark String.hash field @Stable [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Apr 2025 08:26:17 GMT, Per Minborg  wrote:

>> This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and `j.l.String.hashIsZero`. This means the VM can trust these fields to never change which enables constant folding optimizations.
>> 
>> This PR is tested in tier1, tier2, tier3, and tier4 which all pass.
>
> Per Minborg 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 @Stable annotation from hashIsZero, add benchmark
>  - Merge branch 'master' into string-stable-fields
>  - Update copyright year
>  - Annotate fields with @Stable

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24625#pullrequestreview-2784433053

From pminborg at openjdk.org  Tue Apr 22 15:04:20 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 15:04:20 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v71]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with three additional commits since the last revision:

 - Fix failing test (exception message)
 - Rework relayed to rethrown
 - Fix copyright related issues

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/3f71da0c..1670cfdc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=70
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=69-70

  Stats: 35 lines in 11 files changed: 23 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From swen at openjdk.org  Tue Apr 22 15:07:29 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 22 Apr 2025 15:07:29 GMT
Subject: RFR: 8355300: Add final to BitSieve [v2]
In-Reply-To: 
References: 
Message-ID: 

> As the title says, adding final to fields that do not change and BitSieve that will not be inherited will make C2 optimization more friendly.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/math/BitSieve.java
  
  Co-authored-by: Chen Liang 

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24796/files
  - new: https://git.openjdk.org/jdk/pull/24796/files/6e5f708c..1bdbd42a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24796&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24796&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24796.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24796/head:pull/24796

PR: https://git.openjdk.org/jdk/pull/24796

From liach at openjdk.org  Tue Apr 22 15:07:29 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 15:07:29 GMT
Subject: RFR: 8355300: Add final to BitSieve [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Apr 2025 15:04:07 GMT, Shaojin Wen  wrote:

>> As the title says, adding final to fields that do not change and BitSieve that will not be inherited will make C2 optimization more friendly.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/math/BitSieve.java
>   
>   Co-authored-by: Chen Liang 

Looks good in principle.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24796#pullrequestreview-2784441241

From duke at openjdk.org  Tue Apr 22 15:07:56 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 22 Apr 2025 15:07:56 GMT
Subject: RFR: 8077587: BigInteger Roots [v26]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Format code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/9cd136cc..c3bd1b2c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=24-25

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From pminborg at openjdk.org  Tue Apr 22 15:09:49 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 15:09:49 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v72]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Reformat docs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/1670cfdc..f9d423de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=71
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=70-71

  Stats: 13 lines in 1 file changed: 1 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From pminborg at openjdk.org  Tue Apr 22 15:12:50 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 15:12:50 GMT
Subject: Integrated: 8354300: Mark String.hash field @Stable
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Apr 2025 14:47:59 GMT, Per Minborg  wrote:

> This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and `j.l.String.hashIsZero`. This means the VM can trust these fields to never change which enables constant folding optimizations.
> 
> This PR is tested in tier1, tier2, tier3, and tier4 which all pass.

This pull request has now been integrated.

Changeset: 072b8273
Author:    Per Minborg 
URL:       https://git.openjdk.org/jdk/commit/072b8273a4c7bd75bce440e5f1184e2926ed0f78
Stats:     98 lines in 2 files changed: 96 ins; 0 del; 2 mod

8354300: Mark String.hash field @Stable

Reviewed-by: liach, shade, vlivanov

-------------

PR: https://git.openjdk.org/jdk/pull/24625

From pminborg at openjdk.org  Tue Apr 22 15:26:42 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Apr 2025 15:26:42 GMT
Subject: RFR: 8355300: Add final to BitSieve [v2]
In-Reply-To: 
References: 
 
Message-ID: <1KcN6s6-5e_S-mTlruf02w18wa3jJhaO_Bhgu4mZJSw=.9e0a9e6a-26cb-4662-88b8-5d61073b912a@github.com>

On Tue, 22 Apr 2025 15:07:29 GMT, Shaojin Wen  wrote:

>> As the title says, adding final to fields that do not change and BitSieve that will not be inherited will make C2 optimization more friendly.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/math/BitSieve.java
>   
>   Co-authored-by: Chen Liang 

LGTM. The class is package private and so, no external user can ever extend the class or access the fields so we do not need a CSR. Once we get "final means final", performance might go up.

-------------

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24796#pullrequestreview-2784508057

From bpb at openjdk.org  Tue Apr 22 15:35:10 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Apr 2025 15:35:10 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v9]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: 

> Implement the requested methods and add a test thereof.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8354724: Add overlooked "remaining"s to Reader.readAllChars

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/d35d9ebb..42e6f3b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=07-08

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728

PR: https://git.openjdk.org/jdk/pull/24728

From bpb at openjdk.org  Tue Apr 22 15:37:47 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Apr 2025 15:37:47 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v8]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
Message-ID: 

On Tue, 22 Apr 2025 10:16:48 GMT, Alan Bateman  wrote:

> Again, just to say that it's all remaining rather than "all content" as some characters may have been consumed before this method is invoked.

Thanks, that was inadvertently overlooked. See 42e6f3b.

> Now that you have readAllChars, I think it would be good to prototype a readAllLines (or better name) on Reader too. Consuming all characters means that Reader should not need to take on the characteristics of a buffered-Reader.

Shall investigate. There had been some hesitation about introducing the concept of a "line" to `Reader`, but with `readAllChars` we have rather dispensed with that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2054372629

From bpb at openjdk.org  Tue Apr 22 15:42:32 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Apr 2025 15:42:32 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v10]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: <8GQeuJVTpwGUq25H8YXjWKLnkJxXbpzEijwbj1LuL4c=.f77fbe51-6a97-415e-b002-9dc6686ea7bc@github.com>

> Implement the requested methods and add a test thereof.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8354724: Add some more dangling "remaining"s

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/42e6f3b5..1bbb7b12

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=08-09

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728

PR: https://git.openjdk.org/jdk/pull/24728

From bpb at openjdk.org  Tue Apr 22 15:42:32 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Apr 2025 15:42:32 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v8]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
 
Message-ID: 

On Tue, 22 Apr 2025 15:34:43 GMT, Brian Burkhalter  wrote:

>> src/java.base/share/classes/java/io/Reader.java line 401:
>> 
>>> 399:      * Reads all remaining characters into a string.
>>> 400:      *
>>> 401:      * 
 This method reads all content including the line separators in
>> 
>> Again, just to say that it's all remaining rather than "all content" as some characters may have been consumed before this method is invoked.
>> 
>> Now that you have readAllChars, I think it would be good to prototype a readAllLines (or better name) on Reader too. Consuming all characters means that Reader should not need to take on the characteristics of a buffered-Reader.
>
>> Again, just to say that it's all remaining rather than "all content" as some characters may have been consumed before this method is invoked.
> 
> Thanks, that was inadvertently overlooked. See 42e6f3b.
> 
>> Now that you have readAllChars, I think it would be good to prototype a readAllLines (or better name) on Reader too. Consuming all characters means that Reader should not need to take on the characteristics of a buffered-Reader.
> 
> Shall investigate. There had been some hesitation about introducing the concept of a "line" to `Reader`, but with `readAllChars` we have rather dispensed with that.

And more: 1bbb7b1.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2054379507

From alanb at openjdk.org  Tue Apr 22 15:58:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Apr 2025 15:58:51 GMT
Subject: RFR: 8354450: Using a File with a path containing a trailing space
 should fail when alternative data streams are disabled (win) [v3]
In-Reply-To: 
References: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
 
Message-ID: 

On Fri, 18 Apr 2025 18:44:58 GMT, Brian Burkhalter  wrote:

>> In `java.io.WinNTFileSystem::isInvalid`, replace an insufficient test for file path validity with a sufficient test for file path invalidity. Also, add a new test.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8354450: Account for spaces in directory elements; update test

src/java.base/windows/classes/java/io/WinNTFileSystem.java line 376:

> 374:                 return true;
> 375:             theFile = theFile.getParentFile();
> 376:         } while (theFile != null);

The input has already been normalized so I think you can reduce it down to searching getPath for a trailing space or a backslash followed by a space.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24635#discussion_r2054409320

From sgehwolf at openjdk.org  Tue Apr 22 16:03:50 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 22 Apr 2025 16:03:50 GMT
Subject: Withdrawn: 8352689: Allow for hash sum overrides when linking from the
 run-time image
In-Reply-To: 
References: 
Message-ID: 

On Mon, 24 Mar 2025 11:02:15 GMT, Severin Gehwolf  wrote:

> Please review this enhancement which adds a hidden `jlink` option `--sha-overrides` that can be used to provide alternative hash sums for files in an image. Please see the bug for use-cases as to why this is needed. This patch allows for the `--sha-overrides` option to be either specified multiple times or separated by a comma to list multiple hash sum overrides. Alternatively when starting with the `@` character the override options come from a file. The format is the same: `||` triplets, either on the command line or in a file (one per line).
> 
> The added, linux only, test uses `objcopy` to fully strip `libjvm.so` of its symbols with the assumption that this would change the hash sum of the resulting file. Then, a link from the run-time image is being attempted with the added option `--sha-overrides=java.base|lib/server/libjvm.so|` and verifies the link succeeds.
> 
> Having something like that is useful when it gets combined with e.g. `--save-jlink-arg-files` to produce a `jlink` which works out of the box on say JDK builds that modify binaries due to some debug symbols handling outside the JDK builds' control. 
> 
> While using `--ignore-modified-runtime` is an option that is sub-optimal as that would spit out many warnings in the RPM build case, where the user wouldn't control that RPM build to begin with.
> 
> Testing:
> - [x] GHA
> - [x] Some manual tests together with [JDK-8352692](https://bugs.openjdk.org/browse/JDK-8352692) on some JEP 493 enabled builds.
> - [x] `jlink` jtreg tests.
> 
> Thoughts?

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24190

From abarashev at openjdk.org  Tue Apr 22 16:13:49 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 22 Apr 2025 16:13:49 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: 
References: 
Message-ID: <9Sltn-rHaM-4yCCjxAV52Wuc2-j-Q6brdwZyP30551c=.6de1542e-d123-4b37-a199-7675c5c1d2f2@github.com>

On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs  wrote:

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement 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.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 366:

> 364:     }
> 365: 
> 366:     public String chooseServerAlias(String keyType,

This method should have default (package-private) access modifier.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 375:

> 373:     }
> 374: 
> 375:     public String chooseClientAlias(String[] keyTypes, Principal[] issuers,

Same as above, the method shouldn't be public.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054431358
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054432049

From abarashev at openjdk.org  Tue Apr 22 16:17:48 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 22 Apr 2025 16:17:48 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs  wrote:

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement 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.

src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 226:

> 224:                     chc.peerSupportedAuthorities == null ? null :
> 225:                             chc.peerSupportedAuthorities.clone(),
> 226:                     chc.algorithmConstraints);

These `algorithmConstraints` won't include `peerSupportedSignAlgs`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054439669

From abarashev at openjdk.org  Tue Apr 22 16:23:45 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 22 Apr 2025 16:23:45 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs  wrote:

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement 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.

src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 221:

> 219:                             chc.peerSupportedAuthorities.clone(),
> 220:                     engine);
> 221:             // TODO should we have a method that can take QuicTLSEngine?

Yes, I think we should have a method for `QuicTLSEngine` in `X509KeyManagerImpl`. In that new method we should use session's `peerSupportedSignAlgs` to construct algorithm constraints the same way we do it for `SSLSocketImpl` and for `SSLEngineImpl`. This is per TLSv1.3 RFC:
https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054448979

From bpb at openjdk.org  Tue Apr 22 16:32:09 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Apr 2025 16:32:09 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v11]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: 

> Implement the requested methods and add a test thereof.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8354724: Add Reader.readAllLines; test not yet updated

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/1bbb7b12..c4592865

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=09-10

  Stats: 34 lines in 2 files changed: 31 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728

PR: https://git.openjdk.org/jdk/pull/24728

From abarashev at openjdk.org  Tue Apr 22 16:41:46 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 22 Apr 2025 16:41:46 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs  wrote:

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement 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.

src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 265:

> 263: //                    engine, localSupportedSignAlgs, false);
> 264: //        } else {
> 265: //            constraints = SSLAlgorithmConstraints.forEngine(engine, false);

We need these to check peer's certificate against constraints specified in `java.security` config file. It looks like `SSLAlgorithmConstraints` class would need a new `forQuicTLSEngine` method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054475193

From naoto at openjdk.org  Tue Apr 22 16:49:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 22 Apr 2025 16:49:50 GMT
Subject: RFR: 8354343: Hardening of Currency tests for not yet defined
 future ISO 4217 currency [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 21 Apr 2025 23:15:56 GMT, Justin Lu  wrote:

>> Please review this PR which improves future currency checking for ISO 4217 currencies.
>> 
>> Checking for a currency that should not yet exist in the set of available currencies is already done.
>> It should also be explicitly checked that such a currency can not be instantiated as well via the String getter.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move future currencies set up under setUpTestingData()

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24782#pullrequestreview-2784722422

From abarashev at openjdk.org  Tue Apr 22 16:51:51 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 22 Apr 2025 16:51:51 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs  wrote:

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement 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.

src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 286:

> 284:         X509Certificate[] trustedChain = v.validate(chain, null,
> 285:                 Collections.emptyList(),
> 286:                 sslParameters.getAlgorithmConstraints(), authType);

SSLParameter's algorithm constraints don't include constraints specified in `java.security` config file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054488636

From alanb at openjdk.org  Tue Apr 22 16:58:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Apr 2025 16:58:49 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v11]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
Message-ID: <9LPHVgu_b1TQtHqykVY6XMl--dTbLSIZmdqim4hv-70=.8da0476c-c647-459a-b00c-520c42071457@github.com>

On Tue, 22 Apr 2025 16:32:09 GMT, Brian Burkhalter  wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8354724: Add Reader.readAllLines; test not yet updated

src/java.base/share/classes/java/io/Reader.java line 403:

> 401:      * by any one of a line feed ('\n'), a carriage return ('\r'), a carriage
> 402:      * return followed immediately by a line feed, or by reaching the
> 403:      * end-of-file (EOF).

Reader is for reading characters so I think the starting line will say that is reads all remaining characters as lines of text.

In any case, I think you've enough here to help decide if a method should be added to Reader. I think the main observation is that it doesn't require Reader to be buffering.

src/java.base/share/classes/java/io/Reader.java line 426:

> 424:      */
> 425:     public List readAllLines() throws IOException {
> 426:         return readAllChars().lines();

I assume you are missing toList() here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2054491331
PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2054487945

From bpb at openjdk.org  Tue Apr 22 16:58:52 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Apr 2025 16:58:52 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v11]
In-Reply-To: <9LPHVgu_b1TQtHqykVY6XMl--dTbLSIZmdqim4hv-70=.8da0476c-c647-459a-b00c-520c42071457@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 <9LPHVgu_b1TQtHqykVY6XMl--dTbLSIZmdqim4hv-70=.8da0476c-c647-459a-b00c-520c42071457@github.com>
Message-ID: <7J0QtLm-6EKSJN3HC4_rYtlsbLkFy-cBOIIRGhTJcQk=.a5341b33-c86f-4047-8a43-bcb9fb9b401f@github.com>

On Tue, 22 Apr 2025 16:48:43 GMT, Alan Bateman  wrote:

> I assume you are missing toList() here.

Yes, that was stupid. The `make jdk` caught it but I somehow missed the error message.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2054494622

From duke at openjdk.org  Tue Apr 22 17:03:12 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 22 Apr 2025 17:03:12 GMT
Subject: RFR: 8077587: BigInteger Roots [v27]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  An optimization

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/c3bd1b2c..f0d06055

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=25-26

  Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From bpb at openjdk.org  Tue Apr 22 17:12:52 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Apr 2025 17:12:52 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v12]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: 

> Implement the requested methods and add a test thereof.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8354724: Add missing toList(), tweak verbiage; update test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/c4592865..0600f939

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=10-11

  Stats: 15 lines in 2 files changed: 8 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728

PR: https://git.openjdk.org/jdk/pull/24728

From liach at openjdk.org  Tue Apr 22 17:20:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 17:20:15 GMT
Subject: RFR: 8354899: Reduce overhead associated with type switches [v2]
In-Reply-To: 
References: 
Message-ID: 

> The downcallHandle method in Linker has a complex implementation, and type switches is triggered in multiple places in that handle.
> 
> After bytestacks analysis of a simple program that links the native implementation of Class::forName0, it turns out that:
> 1. there are a few missed usages of type switch in ClassFile API
> 2. type switch can speed up generation by using explicit stack maps, as stack map gen is over 50% of the generation instructions because the switch is branch-heavy, but the frames are actually simple.
> 
> These two combined are not that significant in the overall overhead of downcallHandle, but would be helpful for other workloads.

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:

 - Rollback classfile boot speed changes
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/switch-gen-speed
 - Fix adding potentially unbound labels
 - 8354899: Reduce overhead associated with type switches

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24705/files
  - new: https://git.openjdk.org/jdk/pull/24705/files/cbc3fd34..2c17dd1c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24705&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24705&range=00-01

  Stats: 21331 lines in 383 files changed: 18828 ins; 1542 del; 961 mod
  Patch: https://git.openjdk.org/jdk/pull/24705.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24705/head:pull/24705

PR: https://git.openjdk.org/jdk/pull/24705

From naoto at openjdk.org  Tue Apr 22 17:22:49 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 22 Apr 2025 17:22:49 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Apr 2025 12:39:05 GMT, Jan Lahoda  wrote:

>> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
>> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
>> - `java. ... .IO` is no longer automatically imported in any compilation unit
>> - the feature is finalized (i.e. no longer requires `--enable-preview`)
>
> Jan Lahoda has updated the pull request incrementally with seven additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/finalize-concise-source-files' into finalize-concise-source-files
>  - Reverting test commit.
>    
>    This reverts commit 7047cf007cc7de937aa21e96125083ee92932692.
>  - Fixing tests.
>  - Updating copyright year.
>  - Adding bug number to tests.
>  - Fixing IO tests path
>  - Scratch

LGTM. I guess the coordination with Stuart is underway

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24438#pullrequestreview-2784798282

From liach at openjdk.org  Tue Apr 22 17:26:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 17:26:00 GMT
Subject: RFR: 8354899: Reduce overhead associated with type switches [v2]
In-Reply-To: 
References: 
 
Message-ID: <3RUDxCVq03xbf_PrYA4XefXRvGkD1HcN1BkgMWbWtX0=.9ab25735-5a2d-4b80-accb-bdc4778d016f@github.com>

On Tue, 22 Apr 2025 17:20:15 GMT, Chen Liang  wrote:

>> The downcallHandle method in Linker has a complex implementation, and type switches is triggered in multiple places in that handle.
>> 
>> After bytestacks analysis of a simple program that links the native implementation of Class::forName0, it turns out that:
>> 1. there are a few missed usages of type switch in ClassFile API
>> 2. type switch can speed up generation by using explicit stack maps, as stack map gen is over 50% of the generation instructions because the switch is branch-heavy, but the frames are actually simple.
>> 
>> These two combined are not that significant in the overall overhead of downcallHandle, but would be helpful for other workloads.
>
> 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:
> 
>  - Rollback classfile boot speed changes
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/switch-gen-speed
>  - Fix adding potentially unbound labels
>  - 8354899: Reduce overhead associated with type switches

Done, reran `jdk/jdk/classfile langtools/tools/javac/patterns jdk/java/lang/runtime` tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24705#issuecomment-2821997471

From bpb at openjdk.org  Tue Apr 22 17:48:49 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Apr 2025 17:48:49 GMT
Subject: RFR: 8354450: Using a File with a path containing a trailing space
 should fail when alternative data streams are disabled (win) [v3]
In-Reply-To: 
References: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
 
 
Message-ID: 

On Tue, 22 Apr 2025 15:56:10 GMT, Alan Bateman  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8354450: Account for spaces in directory elements; update test
>
> src/java.base/windows/classes/java/io/WinNTFileSystem.java line 376:
> 
>> 374:                 return true;
>> 375:             theFile = theFile.getParentFile();
>> 376:         } while (theFile != null);
> 
> The input has already been normalized so I think you can reduce it down to searching getPath for a trailing space or a backslash followed by a space.

Using `Path.of` with various inputs yields the following:

"root\dir\subdir\file.txt" is valid
"root \dir\subdir\file.txt" is invalid
"root\ dir\subdir\file.txt" is valid
"root\dir \subdir\file.txt" is invalid
"root\dir\ subdir\file.txt" is valid
"root\dir\subdir \file.txt" is invalid
"root\dir\subdir\ file.txt" is valid
"root\dir\subdir\file.txt " is invalid

Apparently that method at least thinks that a backslash followed by a space is acceptable ("invalid" == `InvalidPathException` caught).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24635#discussion_r2054577045

From liach at openjdk.org  Tue Apr 22 18:03:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 18:03:57 GMT
Subject: RFR: 8355301: Simplify the code by using record
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Apr 2025 11:06:17 GMT, Shaojin Wen  wrote:

> As the title says, this is a simple refactoring that simplifies the code by using record.

src/java.base/share/classes/java/lang/Throwable.java line 770:

> 768:      * implementation of printStackTrace.
> 769:      */
> 770:     private interface PrintStreamOrWriter {

This is still too many classes. Can we just pull out `println` to a method like:

private static void println(Object printer, Object o) {
    if (printer instanceof printStream ps) {
        ps.println(o);
    } else {
        ((PrintWriter) printer).println(o);
    }
}

Should be fewer classes to accomplish the same functionality.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24795#discussion_r2054597738

From bpb at openjdk.org  Tue Apr 22 18:08:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Apr 2025 18:08:38 GMT
Subject: RFR: 8354450: Using a File with a path containing a trailing space
 should fail when alternative data streams are disabled (win) [v3]
In-Reply-To: 
References: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
 
 
 
Message-ID: 

On Tue, 22 Apr 2025 17:46:04 GMT, Brian Burkhalter  wrote:

>> src/java.base/windows/classes/java/io/WinNTFileSystem.java line 376:
>> 
>>> 374:                 return true;
>>> 375:             theFile = theFile.getParentFile();
>>> 376:         } while (theFile != null);
>> 
>> The input has already been normalized so I think you can reduce it down to searching getPath for a trailing space or a space followed by a backslash.
>
> Using `Path.of` with various inputs yields the following:
> 
> "root\dir\subdir\file.txt" is valid
> "root \dir\subdir\file.txt" is invalid
> "root\ dir\subdir\file.txt" is valid
> "root\dir \subdir\file.txt" is invalid
> "root\dir\ subdir\file.txt" is valid
> "root\dir\subdir \file.txt" is invalid
> "root\dir\subdir\ file.txt" is valid
> "root\dir\subdir\file.txt " is invalid
> 
> Apparently that method at least thinks that a backslash followed by a space is acceptable ("invalid" == `InvalidPathException` caught).

The equivalent results for the preceding but using `File`, `mkdirs`, and `createNewFile` are:

"root\dir\subdir\file.txt" is valid
"root \dir\subdir\file.txt" is invalid The system cannot find the path specified
"root\ dir\subdir\file.txt" is valid
"root\dir \subdir\file.txt" is invalid The system cannot find the path specified
"root\dir\ subdir\file.txt" is valid
"root\dir\subdir \file.txt" is invalid The system cannot find the path specified
"root\dir\subdir\ file.txt" is valid
"root\dir\subdir\file.txt " is valid

So the current `java.io` restriction matches the `java.nio.file` restriction except for the trailing space in the filename element. Note however that `Path` catches the bad pathname whereas for `java.io` one needs actually to attempt to create the file or directory before invalidity is detected.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24635#discussion_r2054603003

From dfuchs at openjdk.org  Tue Apr 22 18:23:00 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 22 Apr 2025 18:23:00 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <1BMZYXMCLuNxUcGFHy9U6TBYd1pChwilCjVOqXwHQT0=.8f352f4f-afec-40fb-90a5-5d1750b5fc45@github.com>
References: 
 <1BMZYXMCLuNxUcGFHy9U6TBYd1pChwilCjVOqXwHQT0=.8f352f4f-afec-40fb-90a5-5d1750b5fc45@github.com>
Message-ID: <_ZSeC4zTMKKyTWLnkusJQjm5usqAwsC1khEveMwVwnM=.c9918f91-190b-427c-8556-cf2772097e16@github.com>

On Fri, 18 Apr 2025 18:49:19 GMT, Chen Liang  wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement 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.
>
> src/java.net.http/share/classes/java/net/http/HttpRequest.java line 357:
> 
>> 355:          * @since TBD
>> 356:          */
>> 357:         public default  Builder setOption(HttpRequestOption option, T value) { return this; }
> 
> Bikeshed: we usually omit the set prefix for builders.

I actually hesitated quite a bit on this one. We have a precedent with `Builder.setHeader(name, value)` - where the `setHeader` method replaces any value associated with the name with the given value, while `header(name, value)` would just add another value to the list of values associated with the name. I didn't want to give the impression that you could provide several values to the same option - and thus opted for naming that method `setOption`. I could let me be convinced to rename it if there is a strong concensus.

> src/java.net.http/share/classes/java/net/http/HttpResponse.java line 937:
> 
>> 935:                 HttpRequest initiatingRequest,
>> 936:                 HttpRequest pushPromiseRequest,
>> 937:                 PushId pushid,
> 
> (Warning: I know little about HTTP, my assumptions and thus whole argument may be invalid below!)
> 
> This feels like users need to use push ids as units of synchronization on this handler, such as tracking this with a ConcurrentHashMap.
> 
> Is it possible for users to instead provide a `Function` in `HttpClient::sendAsync`? I think this might make it easier for users as they no longer need to think about concurrency for different ids.

PushId is an HTTP/3 concept. It would be strange to have a generic method (sendAsync) that you could call with any requests, but with a parameter that could only be used for HTTP/3. We don't have pushIds for HTTP/2. I don't think we would want to take this route.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054622121
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054623922

From jrose at openjdk.org  Tue Apr 22 18:26:57 2025
From: jrose at openjdk.org (John R Rose)
Date: Tue, 22 Apr 2025 18:26:57 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 21 Apr 2025 20:12:19 GMT, Chen Liang  wrote:

>> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list".
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine validation and defensive copying

src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 58:

> 56:  * The HotSpot VM checks, when loading a class, the consistency of recognized
> 57:  * methods and {@code @IntrinsicCandidate} annotations, unless the {@code
> 58:  * CheckIntrinsics} VM flag is disabled.



Even if an intrinsic is available the VM is not obligated to use it.  For example,
the bytecodes of an intrinsic method may be executed by lower tiers of VM
execution, while higher tiers may replace the bytecodes with specialized
assembly code and/or compiler IR.  Therefore, intrinsic implementors must
ensure that non-bytecode execution has (in an application-specific sense)
the same results as execution of the actual Java code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2054639422

From jrose at openjdk.org  Tue Apr 22 18:41:41 2025
From: jrose at openjdk.org (John R Rose)
Date: Tue, 22 Apr 2025 18:41:41 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 22 Apr 2025 18:23:52 GMT, John R Rose  wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refine validation and defensive copying
>
> src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 58:
> 
>> 56:  * The HotSpot VM checks, when loading a class, the consistency of recognized
>> 57:  * methods and {@code @IntrinsicCandidate} annotations, unless the {@code
>> 58:  * CheckIntrinsics} VM flag is disabled.
> 
> 

> Even if an intrinsic is available the VM is not obligated to use it.  For example,
> the bytecodes of an intrinsic method may be executed by lower tiers of VM
> execution, while higher tiers may replace the bytecodes with specialized
> assembly code and/or compiler IR.  Therefore, intrinsic implementors must
> ensure that non-bytecode execution has (in an application-specific sense)
> the same results as execution of the actual Java code.  Also, persons not
> directly involved with maintaining the Java libraries or the HotSpot VM can
> usually ignore the {@code @IntrinsicCandidate} annotation, when reasoning
> about the actions of the method.  Such persons must not assume, however,
> that checks for nulls, out-of-bounds indexes, and wrong types will be performed
> by the intrinsic, even though normal Java execution always performs such checks.

And for arrays, a footnote might be appropriate:




For some highly optimized algorithms, it may be impractical to ensure that array
data is read or written only once by the intrinsic.  If the caller of the intrinsic
cannot guarantee that such array data is unshared, then the caller must also
document the effects of race conditions on it.  (Such a race occurs when another
thread writes the array data during the execution of the intrinsic.)  For example,
the documentation can simply say that the result is undefined if a race happens.


And maybe, after that, something more about type safety:




In no case may any intrinsic be allowed to perform an operation that fails to be
type safe.  It must not indirect a null pointer; it must not access a field or method
on an object which does not possess that field or method; it must not access
an element of an array not actually present in the array; and it must not
manipulate managed references in a way that prevents the GC from managing
them.  The caller of the intrinsic is fully responsible for preventing every kind
of type safety violation, in the case (the common case) that the intrinsic itself
does not itself somehow prevent the violation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2054665206

From jrose at openjdk.org  Tue Apr 22 18:44:40 2025
From: jrose at openjdk.org (John R Rose)
Date: Tue, 22 Apr 2025 18:44:40 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 22 Apr 2025 18:38:42 GMT, John R Rose  wrote:

>> src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 58:
>> 
>>> 56:  * The HotSpot VM checks, when loading a class, the consistency of recognized
>>> 57:  * methods and {@code @IntrinsicCandidate} annotations, unless the {@code
>>> 58:  * CheckIntrinsics} VM flag is disabled.
>> 
>> 

>> Even if an intrinsic is available the VM is not obligated to use it.  For example,
>> the bytecodes of an intrinsic method may be executed by lower tiers of VM
>> execution, while higher tiers may replace the bytecodes with specialized
>> assembly code and/or compiler IR.  Therefore, intrinsic implementors must
>> ensure that non-bytecode execution has (in an application-specific sense)
>> the same results as execution of the actual Java code.  Also, persons not
>> directly involved with maintaining the Java libraries or the HotSpot VM can
>> usually ignore the {@code @IntrinsicCandidate} annotation, when reasoning
>> about the actions of the method.  Such persons must not assume, however,
>> that checks for nulls, out-of-bounds indexes, and wrong types will be performed
>> by the intrinsic, even though normal Java execution always performs such checks.
>
> And for arrays, a footnote might be appropriate:
> 
> 
> 

> For some highly optimized algorithms, it may be impractical to ensure that array
> data is read or written only once by the intrinsic.  If the caller of the intrinsic
> cannot guarantee that such array data is unshared, then the caller must also
> document the effects of race conditions on it.  (Such a race occurs when another
> thread writes the array data during the execution of the intrinsic.)  For example,
> the documentation can simply say that the result is undefined if a race happens.
> 
> 
> And maybe, after that, something more about type safety:
> 
> 
> 

> In no case may any intrinsic be allowed to perform an operation that fails to be
> type safe.  It must not indirect a null pointer; it must not access a field or method
> on an object which does not possess that field or method; it must not access
> an element of an array not actually present in the array; and it must not
> manipulate managed references in a way that prevents the GC from managing
> them.  The caller of the intrinsic is fully responsible for preventing every kind
> of type safety violation, in the case (the common case) that the intrinsic itself
> does not itself somehow prevent the violation.

In the new design, the above "footnotes" go at the bottom.  They explain why the rules prescribed at the top are important.  In effect, inform aggressive implementors how far they may bend those rules.  Sometimes the rules do get bent, sometimes to allow unspecified behavior, but never so far as to allow a type safety violation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2054672049

From liach at openjdk.org  Tue Apr 22 18:50:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 18:50:48 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <_ZSeC4zTMKKyTWLnkusJQjm5usqAwsC1khEveMwVwnM=.c9918f91-190b-427c-8556-cf2772097e16@github.com>
References: 
 <1BMZYXMCLuNxUcGFHy9U6TBYd1pChwilCjVOqXwHQT0=.8f352f4f-afec-40fb-90a5-5d1750b5fc45@github.com>
 <_ZSeC4zTMKKyTWLnkusJQjm5usqAwsC1khEveMwVwnM=.c9918f91-190b-427c-8556-cf2772097e16@github.com>
Message-ID: 

On Tue, 22 Apr 2025 18:18:51 GMT, Daniel Fuchs  wrote:

>> src/java.net.http/share/classes/java/net/http/HttpRequest.java line 357:
>> 
>>> 355:          * @since TBD
>>> 356:          */
>>> 357:         public default  Builder setOption(HttpRequestOption option, T value) { return this; }
>> 
>> Bikeshed: we usually omit the set prefix for builders.
>
> I actually hesitated quite a bit on this one. We have a precedent with `Builder.setHeader(name, value)` - where the `setHeader` method replaces any value associated with the name with the given value, while `header(name, value)` would just add another value to the list of values associated with the name. I didn't want to give the impression that you could provide several values to the same option - and thus opted for naming that method `setOption`. I could let me be convinced to rename it if there is a strong concensus.

Didn't notice we already use `set` prefix in this builder. All good; consistency is more important.

>> src/java.net.http/share/classes/java/net/http/HttpResponse.java line 937:
>> 
>>> 935:                 HttpRequest initiatingRequest,
>>> 936:                 HttpRequest pushPromiseRequest,
>>> 937:                 PushId pushid,
>> 
>> (Warning: I know little about HTTP, my assumptions and thus whole argument may be invalid below!)
>> 
>> This feels like users need to use push ids as units of synchronization on this handler, such as tracking this with a ConcurrentHashMap.
>> 
>> Is it possible for users to instead provide a `Function` in `HttpClient::sendAsync`? I think this might make it easier for users as they no longer need to think about concurrency for different ids.
>
> PushId is an HTTP/3 concept. It would be strange to have a generic method (sendAsync) that you could call with any requests, but with a parameter that could only be used for HTTP/3. We don't have pushIds for HTTP/2. I don't think we would want to take this route.

Do users need to track the push ids in a thread-safe data structure like ConcurrentHashMap in a PushPromiseHandler?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054677703
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054679688

From abarashev at openjdk.org  Tue Apr 22 18:58:58 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 22 Apr 2025 18:58:58 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs  wrote:

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement 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.

test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 86:

> 84:     public static void main(String[] args) throws Exception {
> 85:         // re-enable 3DES
> 86:         Security.setProperty("jdk.tls.disabledAlgorithms", "");

Use `SecurityUtils.removeFromDisabledAlgs` and only remove 3DES from this property.

test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 95:

> 93:         //System.setProperty("javax.net.ssl.keyStorePassword", PASSWORD);
> 94:         //System.setProperty("javax.net.ssl.trustStore", KEYSTORE);
> 95:         //System.setProperty("javax.net.ssl.trustStorePassword", PASSWORD);

Why we don't delete this?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054689179
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054690345

From smarks at openjdk.org  Tue Apr 22 18:59:46 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 22 Apr 2025 18:59:46 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 22 Apr 2025 08:14:23 GMT, Alan Bateman  wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add clause about handling of malformed/unmappable bytes.
>
> src/java.base/share/classes/java/lang/IO.java line 41:
> 
>> 39:  * The {@link #readln()} and {@link #readln(String)} methods decode bytes read from
>> 40:  * {@code System.in} into characters. The charset used for decoding is specified by the
>> 41:  * {@link System#getProperties stdin.encoding} property. If this property is not present,
> 
> @stuart-marks Are you planning to propose/integrate pull/24738 in advance of the JEP update? Asking because this paragraph will need to be adjusted if pull/24738 doesn't go in first.

Depends on how close you think 24738 is to being ready. As it stands it seems ok; but I'm still looking at the potential impact on other part of the JDK. In particular are there other JDK APIs that should be adjusted to mention `stdin.encoding`?

As for the impact here, if 24738 doesn't go in first, then I'm not quite sure what this should say. I guess it could say "default charset" or something and then it could be amended with a bugfix later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2054690796

From abarashev at openjdk.org  Tue Apr 22 19:02:46 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 22 Apr 2025 19:02:46 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: 
References: 
Message-ID: <9rWMdJ_KuW5Auws9DtD_pOWt2Mb4-nGLBDmN0DLFA_0=.c8106398-609d-482d-a5bf-b8b78bb8144d@github.com>

On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs  wrote:

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement 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.

test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 96:

> 94:         //System.setProperty("javax.net.ssl.trustStore", KEYSTORE);
> 95:         //System.setProperty("javax.net.ssl.trustStorePassword", PASSWORD);
> 96:         SSLContext context = new SimpleSSLContext().get();

FYI: We are moving away from using keystore files to generating keystores on the fly as needed. `SimpleSSLContext` is using a keystore file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054695885

From abarashev at openjdk.org  Tue Apr 22 19:13:48 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 22 Apr 2025 19:13:48 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs  wrote:

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement 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.

We would need a unit test testing QUIC with `jdk.tls.disabledAlgorithms` and `jdk.certpath.disabledAlgorithms` algorithm constraints in `java.security` file. Those are currently being ignored as far as I can tell..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24751#issuecomment-2822240636

From abarashev at openjdk.org  Tue Apr 22 19:13:49 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 22 Apr 2025 19:13:49 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <9rWMdJ_KuW5Auws9DtD_pOWt2Mb4-nGLBDmN0DLFA_0=.c8106398-609d-482d-a5bf-b8b78bb8144d@github.com>
References: 
 <9rWMdJ_KuW5Auws9DtD_pOWt2Mb4-nGLBDmN0DLFA_0=.c8106398-609d-482d-a5bf-b8b78bb8144d@github.com>
Message-ID: 

On Tue, 22 Apr 2025 18:59:57 GMT, Artur Barashev  wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement 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.
>
> test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 96:
> 
>> 94:         //System.setProperty("javax.net.ssl.trustStore", KEYSTORE);
>> 95:         //System.setProperty("javax.net.ssl.trustStorePassword", PASSWORD);
>> 96:         SSLContext context = new SimpleSSLContext().get();
> 
> FYI: We are moving away from using keystore files to generating keystores on the fly as needed. `SimpleSSLContext` is using a keystore file.

`MD5NotAllowedInTLS13CertificateSignature` contains an example.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054710098

From dfuchs at openjdk.org  Tue Apr 22 19:23:49 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 22 Apr 2025 19:23:49 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: 
References: 
 <1BMZYXMCLuNxUcGFHy9U6TBYd1pChwilCjVOqXwHQT0=.8f352f4f-afec-40fb-90a5-5d1750b5fc45@github.com>
 <_ZSeC4zTMKKyTWLnkusJQjm5usqAwsC1khEveMwVwnM=.c9918f91-190b-427c-8556-cf2772097e16@github.com>
 
Message-ID: <3dsq7ir0jGHmoyAUr-mtFV5gxoWTj658lUVa7hJizDY=.46e944dd-4ffa-42fc-b877-c3ff4dc156c4@github.com>

On Tue, 22 Apr 2025 18:48:06 GMT, Chen Liang  wrote:

>> PushId is an HTTP/3 concept. It would be strange to have a generic method (sendAsync) that you could call with any requests, but with a parameter that could only be used for HTTP/3. We don't have pushIds for HTTP/2. I don't think we would want to take this route.
>
> Do users need to track the push ids in a thread-safe data structure like ConcurrentHashMap in a PushPromiseHandler?

Yes, they would need to provide a thread safe PushPromisHandler, but not in a way that would be significantly different than how they would need to do it for HTTP/2 server pushes, if they used the same handler with different concurrent requests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054721621

From rriggs at openjdk.org  Tue Apr 22 19:23:50 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Apr 2025 19:23:50 GMT
Subject: RFR: 8355301: Simplify the code by using record
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Apr 2025 11:06:17 GMT, Shaojin Wen  wrote:

> As the title says, this is a simple refactoring that simplifies the code by using record.

Both the bug report and the PR description are inadequate. 
They do not identity what code is simplified.

-------------

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24795#pullrequestreview-2785112969

From asemenyuk at openjdk.org  Tue Apr 22 19:29:50 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 22 Apr 2025 19:29:50 GMT
Subject: RFR: 8355328: Improve negative tests coverage for jpackage signing
Message-ID: 

Add tests covering `error.explicit-sign-no-cert` error ID to ErrorTest.

If signing identity validation fails, jpackage outputs three messages constructed from the following string IDs: `error.cert.not.found`, `error.explicit-sign-no-cert`, and `error.explicit-sign-no-cert.advice`.

`TKit.TextStreamVerifier.andThen()` method doesn't work correctly when combining more than two instances of `TKit.TextStreamVerifier` class. To address this bug and analyze jpackage's output for three expected strings when a non-existent signing identity is specified, the `TKit.TextStreamVerifier.andThen()` method was replaced with the `TKit.TextStreamVerifier.Group` class. Changes in other tests are a result of this change.

-------------

Commit messages:
 - Fix bad merge
 - Fix compilation error
 - Better negative tests coverage
 - Rework TKit.TextStreamVerifier.andThen() as it didn't work if called multiple times. Change signature from TKit.TextStreamVerifier.apply(Stream) to TKit.TextStreamVerifier.apply(Iterator) and TKit.TextStreamVerifier.apply(List)

Changes: https://git.openjdk.org/jdk/pull/24786/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24786&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355328
  Stats: 188 lines in 19 files changed: 117 ins; 18 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/24786.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24786/head:pull/24786

PR: https://git.openjdk.org/jdk/pull/24786

From asemenyuk at openjdk.org  Tue Apr 22 19:29:51 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 22 Apr 2025 19:29:51 GMT
Subject: RFR: 8355328: Improve negative tests coverage for jpackage signing
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Apr 2025 00:43:24 GMT, Alexey Semenyuk  wrote:

> Add tests covering `error.explicit-sign-no-cert` error ID to ErrorTest.
> 
> If signing identity validation fails, jpackage outputs three messages constructed from the following string IDs: `error.cert.not.found`, `error.explicit-sign-no-cert`, and `error.explicit-sign-no-cert.advice`.
> 
> `TKit.TextStreamVerifier.andThen()` method doesn't work correctly when combining more than two instances of `TKit.TextStreamVerifier` class. To address this bug and analyze jpackage's output for three expected strings when a non-existent signing identity is specified, the `TKit.TextStreamVerifier.andThen()` method was replaced with the `TKit.TextStreamVerifier.Group` class. Changes in other tests are a result of this change.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24786#issuecomment-2822273911

From mli at openjdk.org  Tue Apr 22 19:37:51 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 22 Apr 2025 19:37:51 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Apr 2025 18:03:47 GMT, Vladimir Ivanov  wrote:

>> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
>> 
>> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
>> 
>> The patch consists of the following parts:
>>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
>> 
>> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
>> 
>> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
>> 
>> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
>> 
>> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
>> 
>> Thanks!
>
> Vladimir Ivanov 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 24 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into vector.math.01.java
>  - RVV and SVE adjustments
>  - fix broken merge
>  - Merge branch 'master' into vector.math.01.java
>  - Fix debugName handling
>  - Merge branch 'master' into vector.math.01.java
>  - RVV and SVE adjustments
>  - Merge branch 'master' into vector.math.01.java
>  - Fix windows-aarch64 build failure
>  - features_string -> cpu_info_string
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/88f7b422...88eacc48

I just ran some basic tests on riscv, seems there are some issues, also have some comments.

src/hotspot/share/runtime/abstract_vm_version.cpp line 349:

> 347:   assert(features_offset <= cpu_info_string_len, "");
> 348:   if (features_offset < cpu_info_string_len) {
> 349:     assert(cpu_info_string[features_offset + 0] == ',', "");

This assert fails on riscv.

src/hotspot/share/runtime/abstract_vm_version.hpp line 61:

> 59:   static const char* _features_string;
> 60: 
> 61:   static const char* _cpu_info_string;

Not quite sure the reason to introduce `_cpu_info_string`.
Seems to me you could just use _features_string, and remove _cpu_info_string and its related code, e.g. `extract_features_string`. Please check the code in `test/lib/jdk/test/whitebox/cpuinfo/CPUInfo.java`

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/CPUFeatures.java line 45:

> 43:         String featuresString = VectorSupport.getCPUFeatures();
> 44:         debug(featuresString);
> 45:         String[] features = featuresString.toLowerCase(Locale.ROOT).split(", "); // ", " is used as a delimiter

On riscv, it's splitted by " ",  for the fix please refer to CPUInfo.java in test.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/CPUFeatures.java line 82:

> 80:         return features;
> 81:     }
> 82: }

Maybe an extra line needed at the end of this file?

-------------

PR Review: https://git.openjdk.org/jdk/pull/24462#pullrequestreview-2784177749
PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2054468091
PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2054692791
PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2054472788
PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2054157269

From mli at openjdk.org  Tue Apr 22 19:37:51 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 22 Apr 2025 19:37:51 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v10]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 22 Apr 2025 16:34:21 GMT, Hamlin Li  wrote:

>> Vladimir Ivanov 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 24 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into vector.math.01.java
>>  - RVV and SVE adjustments
>>  - fix broken merge
>>  - Merge branch 'master' into vector.math.01.java
>>  - Fix debugName handling
>>  - Merge branch 'master' into vector.math.01.java
>>  - RVV and SVE adjustments
>>  - Merge branch 'master' into vector.math.01.java
>>  - Fix windows-aarch64 build failure
>>  - features_string -> cpu_info_string
>>  - ... and 14 more: https://git.openjdk.org/jdk/compare/88f7b422...88eacc48
>
> src/hotspot/share/runtime/abstract_vm_version.cpp line 349:
> 
>> 347:   assert(features_offset <= cpu_info_string_len, "");
>> 348:   if (features_offset < cpu_info_string_len) {
>> 349:     assert(cpu_info_string[features_offset + 0] == ',', "");
> 
> This assert fails on riscv.

A simple fix could be:

diff --git a/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp b/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp
index 484a2a645aa..a785dc65c9e 100644
--- a/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp
+++ b/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp
@@ -196,25 +196,12 @@ void VM_Version::setup_cpu_available_features() {
 
   _cpu_info_string = os::strdup(buf);
 
-  _features_string = extract_features_string(_cpu_info_string,
-                                             strnlen(_cpu_info_string, sizeof(buf)),
-                                             features_offset);
+  _features_string = _cpu_info_string;
 }

> src/hotspot/share/runtime/abstract_vm_version.hpp line 61:
> 
>> 59:   static const char* _features_string;
>> 60: 
>> 61:   static const char* _cpu_info_string;
> 
> Not quite sure the reason to introduce `_cpu_info_string`.
> Seems to me you could just use _features_string, and remove _cpu_info_string and its related code, e.g. `extract_features_string`. Please check the code in `test/lib/jdk/test/whitebox/cpuinfo/CPUInfo.java`

Mayber in `CPUFeatures`, could use the similar code as `CPUInfo` to split the cpu string into cpu features?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2054485082
PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2054697247

From abarashev at openjdk.org  Tue Apr 22 19:38:47 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 22 Apr 2025 19:38:47 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs  wrote:

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement 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.

src/java.base/share/classes/sun/security/ssl/CertificateMessage.java line 1221:

> 1219:                         tm.checkClientTrusted(
> 1220:                                 certs.clone(),
> 1221:                                 authType);

This call doesn't check against `SSLAlgorithmConstraints` unlike 2 calls for `SSLSocket` and `SSLEngine` above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054738885

From jiangli at openjdk.org  Tue Apr 22 20:38:44 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 22 Apr 2025 20:38:44 GMT
Subject: RFR: 8354898: jdk/internal/loader/NativeLibraries/Main.java fails
 on static JDK
In-Reply-To: <68U_vj5WY81keMaVqgpGwGWjvOEfBhIcR1kpf_noOgk=.49e2b7b2-9a0c-4187-b702-cf3cb5b1255d@github.com>
References: 
 <68U_vj5WY81keMaVqgpGwGWjvOEfBhIcR1kpf_noOgk=.49e2b7b2-9a0c-4187-b702-cf3cb5b1255d@github.com>
Message-ID: 

On Tue, 22 Apr 2025 07:37:45 GMT, Jaikiran Pai  wrote:

> Hello Jiangli, can you add a few more details to the linked JBS issue? If I understand this change correctly, then what's being proposed in this PR seems to indicate that the `jdk.internal.loader.RawNativeLibraries` is unable to load `libzip` whose `Path` is determined by a call to the `System.mapLibraryName(...)` standard API. I don't currently have access to a static JDK. Can you include the `Path` that's returned for `System.mapLibraryName("zip")` on a static JDK?

@jaikiran Added details in https://bugs.openjdk.org/browse/JDK-8354898, thanks for the suggestion. I also added command line examples for building `static-jdk` and the current method for running jtreg tests on `static-jdk`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24704#issuecomment-2822427766

From liach at openjdk.org  Tue Apr 22 20:58:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 20:58:21 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v3]
In-Reply-To: 
References: 
Message-ID: <_1ljTpPgVmfrKlQWZhnHViS10crap9saTmU-H3eBux4=.9d36c6c2-5015-45d9-9ffd-0560a4a7ed5b@github.com>

> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list".

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Updates, thanks to John

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24777/files
  - new: https://git.openjdk.org/jdk/pull/24777/files/e8adab3c..e2e1da5e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24777&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24777&range=01-02

  Stats: 60 lines in 1 file changed: 40 ins; 10 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/24777.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24777/head:pull/24777

PR: https://git.openjdk.org/jdk/pull/24777

From liach at openjdk.org  Tue Apr 22 21:00:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 21:00:48 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 21 Apr 2025 20:12:19 GMT, Chen Liang  wrote:

>> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list".
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine validation and defensive copying

I have incorporated these "footnote" as "blockquote" notes in the middle of the docs, immediately after their relevant paragraphs. Intellij renders them with extra indentation, which IMO has nice appearance.

Now, the docs have a few paragraphs:

1. Intro to intrinsics and intrinsification
2. Intrinsification can happen at any time, need consistency
3. Candidate methods and intrinsics - the arg assumptions are exported from intrinsics to candidate methods, callers fully responsible (footnote: list of type safety breaches)
4. Encapsulation of candidate with callers, and arg checks performed by callers (and array arg check perks)
5. VM also does consistency check for this annotation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24777#issuecomment-2822469588

From liach at openjdk.org  Tue Apr 22 21:03:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 21:03:48 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v2]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Tue, 22 Apr 2025 18:42:01 GMT, John R Rose  wrote:

>> And for arrays, a footnote might be appropriate:
>> 
>> 
>> 

>> For some highly optimized algorithms, it may be impractical to ensure that array
>> data is read or written only once by the intrinsic.  If the caller of the intrinsic
>> cannot guarantee that such array data is unshared, then the caller must also
>> document the effects of race conditions on it.  (Such a race occurs when another
>> thread writes the array data during the execution of the intrinsic.)  For example,
>> the documentation can simply say that the result is undefined if a race happens.
>> 
>> 
>> And maybe, after that, something more about type safety:
>> 
>> 
>> 

>> In no case may any intrinsic be allowed to perform an operation that fails to be
>> type safe.  It must not indirect a null pointer; it must not access a field or method
>> on an object which does not possess that field or method; it must not access
>> an element of an array not actually present in the array; and it must not
>> manipulate managed references in a way that prevents the GC from managing
>> them.  The caller of the intrinsic is fully responsible for preventing every kind
>> of type safety violation, in the case (the common case) that the intrinsic itself
>> does not itself somehow prevent the violation.
>
> In the new design, the above "footnotes" go at the bottom.  They explain why the rules prescribed at the top are important.  In effect, inform aggressive implementors how far they may bend those rules.  Sometimes the rules do get bent, sometimes to allow unspecified behavior, but never so far as to allow a type safety violation.

I still believe these information are important and better kept inline; inlined them with blockquote tags.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2054866335

From jiangli at openjdk.org  Tue Apr 22 21:14:16 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 22 Apr 2025 21:14:16 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK
Message-ID: 

Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.

`NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.

In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.

-------------

Commit messages:
 - Use NativeLibraries.loadLibrary() to get the libsyslookup. This works on both regular and static JDK.

Changes: https://git.openjdk.org/jdk/pull/24801/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24801&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355080
  Stats: 40 lines in 5 files changed: 23 ins; 7 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/24801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24801/head:pull/24801

PR: https://git.openjdk.org/jdk/pull/24801

From jrose at openjdk.org  Tue Apr 22 21:20:40 2025
From: jrose at openjdk.org (John R Rose)
Date: Tue, 22 Apr 2025 21:20:40 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v2]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: <_HuuRIBzg-gElqzCelP9RwQqjMMDNUb-WJHHyq-NWFg=.ac3d8690-f860-468e-8d3e-a0d5ad81bae9@github.com>

On Tue, 22 Apr 2025 21:01:13 GMT, Chen Liang  wrote:

>> In the new design, the above "footnotes" go at the bottom.  They explain why the rules prescribed at the top are important.  In effect, inform aggressive implementors how far they may bend those rules.  Sometimes the rules do get bent, sometimes to allow unspecified behavior, but never so far as to allow a type safety violation.
>
> I still believe these information are important and better kept inline; inlined them with blockquote tags.

+1 from me on your preference.  In formulating footnotes I was trying to respect your attempt to put the most important bits at the top.  I actually prefer the "sidebars" (what you have) to "footnotes".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2054895659

From jrose at openjdk.org  Tue Apr 22 21:28:46 2025
From: jrose at openjdk.org (John R Rose)
Date: Tue, 22 Apr 2025 21:28:46 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v3]
In-Reply-To: <_1ljTpPgVmfrKlQWZhnHViS10crap9saTmU-H3eBux4=.9d36c6c2-5015-45d9-9ffd-0560a4a7ed5b@github.com>
References: 
 <_1ljTpPgVmfrKlQWZhnHViS10crap9saTmU-H3eBux4=.9d36c6c2-5015-45d9-9ffd-0560a4a7ed5b@github.com>
Message-ID: <2EPrvfeY1s839YjeMEjCiBCRk0xU5GgEyxmSZtmM47c=.7bedef1a-e1fc-4a98-9100-aed7c7472e10@github.com>

On Tue, 22 Apr 2025 20:58:21 GMT, Chen Liang  wrote:

>> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list".
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates, thanks to John

src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 34:

> 32:  * recognized by {@code vmIntrinsics.hpp} and may be subject to intrinsification
> 33:  * by the HotSpot VM (see {@code LibraryCallKit::try_to_inline} in {@code
> 34:  * library_call.cpp}) if an intrinsic is available.  Intrinsification replaces a

This lead sentence is too long to read conveniently, partly because it is broken up by a parenthetical.

Suggest:


The `@IntrinsicCandidate` indicates that an annotated method is
recognized by `vmIntrinsics.hpp` and may be subject to intrinsification
by the HotSpot VM.  (See `LibraryCallKit::try_to_inline` in `library_call.cpp`
for logic that checks if an intrinsic is available and applicable at a given call site.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2054909244

From jrose at openjdk.org  Tue Apr 22 21:31:45 2025
From: jrose at openjdk.org (John R Rose)
Date: Tue, 22 Apr 2025 21:31:45 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v3]
In-Reply-To: <_1ljTpPgVmfrKlQWZhnHViS10crap9saTmU-H3eBux4=.9d36c6c2-5015-45d9-9ffd-0560a4a7ed5b@github.com>
References: 
 <_1ljTpPgVmfrKlQWZhnHViS10crap9saTmU-H3eBux4=.9d36c6c2-5015-45d9-9ffd-0560a4a7ed5b@github.com>
Message-ID: 

On Tue, 22 Apr 2025 20:58:21 GMT, Chen Liang  wrote:

>> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list".
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates, thanks to John

FWIW I posted a formatted version here:
https://gist.github.com/rose00/b6f7b2d18bae20b9cd277672c05075b5

It made it easier for me to review, although it is likely to go out of date quickly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24777#issuecomment-2822524512

From liach at openjdk.org  Tue Apr 22 21:35:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 21:35:44 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Apr 2025 21:08:56 GMT, Jiangli Zhou  wrote:

> Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
> 
> `NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.
> 
> In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.

`sysLookup` does look much cleaner compared to `jdkLibraryPath`.

src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java line 135:

> 133:     @SuppressWarnings("restricted")
> 134:     private static SymbolLookup sysLookup() {
> 135:         NativeLibraries libs = jdk.internal.loader.NativeLibraries.newInstance(null);

Suggestion:

        NativeLibraries libs = NativeLibraries.newInstance(null);

We already imported this class.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24801#pullrequestreview-2785431747
PR Review Comment: https://git.openjdk.org/jdk/pull/24801#discussion_r2054915197

From liach at openjdk.org  Tue Apr 22 21:57:19 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 21:57:19 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v4]
In-Reply-To: 
References: 
Message-ID: 

> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list".

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Shorter first sentence

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24777/files
  - new: https://git.openjdk.org/jdk/pull/24777/files/e2e1da5e..d7b652e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24777&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24777&range=02-03

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24777.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24777/head:pull/24777

PR: https://git.openjdk.org/jdk/pull/24777

From almatvee at openjdk.org  Tue Apr 22 21:59:43 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 22 Apr 2025 21:59:43 GMT
Subject: RFR: 8355328: Improve negative tests coverage for jpackage signing
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Apr 2025 00:43:24 GMT, Alexey Semenyuk  wrote:

> Add tests covering `error.explicit-sign-no-cert` error ID to ErrorTest.
> 
> If signing identity validation fails, jpackage outputs three messages constructed from the following string IDs: `error.cert.not.found`, `error.explicit-sign-no-cert`, and `error.explicit-sign-no-cert.advice`.
> 
> `TKit.TextStreamVerifier.andThen()` method doesn't work correctly when combining more than two instances of `TKit.TextStreamVerifier` class. To address this bug and analyze jpackage's output for three expected strings when a non-existent signing identity is specified, the `TKit.TextStreamVerifier.andThen()` method was replaced with the `TKit.TextStreamVerifier.Group` class. Changes in other tests are a result of this change.

Looks good with minor comment.

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java line 982:

> 980:             createException = other.createException;
> 981:             anotherVerifier = other.anotherVerifier;
> 982:             value= other.value;

Space before =.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24786#pullrequestreview-2785463087
PR Review Comment: https://git.openjdk.org/jdk/pull/24786#discussion_r2054933805

From bpb at openjdk.org  Tue Apr 22 22:21:46 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Apr 2025 22:21:46 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v12]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
Message-ID: <-3ABL_c-eOl4lRMSdwh8RWV_1Md628u_0u-KPUCuzIg=.33f83b76-8f15-4b5b-b3b5-a9da17d93d19@github.com>

On Tue, 22 Apr 2025 17:12:52 GMT, Brian Burkhalter  wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8354724: Add missing toList(), tweak verbiage; update test

As a footnote, the throughput of the `BufferedRead.readAllLines` override is marginally greater than that of `Reader.readAllLines`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2822602982

From bpb at openjdk.org  Tue Apr 22 22:21:47 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Apr 2025 22:21:47 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v11]
In-Reply-To: <7J0QtLm-6EKSJN3HC4_rYtlsbLkFy-cBOIIRGhTJcQk=.a5341b33-c86f-4047-8a43-bcb9fb9b401f@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 <9LPHVgu_b1TQtHqykVY6XMl--dTbLSIZmdqim4hv-70=.8da0476c-c647-459a-b00c-520c42071457@github.com>
 <7J0QtLm-6EKSJN3HC4_rYtlsbLkFy-cBOIIRGhTJcQk=.a5341b33-c86f-4047-8a43-bcb9fb9b401f@github.com>
Message-ID: 

On Tue, 22 Apr 2025 16:53:30 GMT, Brian Burkhalter  wrote:

>> src/java.base/share/classes/java/io/Reader.java line 426:
>> 
>>> 424:      */
>>> 425:     public List readAllLines() throws IOException {
>>> 426:         return readAllChars().lines();
>> 
>> I assume you are missing toList() here.
>
>> I assume you are missing toList() here.
> 
> Yes, that was stupid. The `make jdk` caught it but I somehow missed the error message.

Fixed in 0600f93.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2054969039

From smarks at openjdk.org  Tue Apr 22 23:04:32 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 22 Apr 2025 23:04:32 GMT
Subject: RFR: 8350703: Add standard system property stdin.encoding
Message-ID: 

* Windows and Unix: set sprops.stdin_encoding if connected to a console
* Add specs for stdin.encoding
* Adjust specs to change "undefined" to "unspecified"
* Rewrite System.in spec to refer to new property and to clarify usage with classes that perform encoding
* Update property test

-------------

Commit messages:
 - Even moar wordsmithing.
 - moar wordsmithing
 - wordsmith
 - Revise spec of System.in to mention stdin.encoding.
 - Fix typo stdout => stdin
 - 8350703: first cut at stdin.encoding

Changes: https://git.openjdk.org/jdk/pull/24738/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24738&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350703
  Stats: 48 lines in 7 files changed: 30 ins; 1 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/24738.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24738/head:pull/24738

PR: https://git.openjdk.org/jdk/pull/24738

From bchristi at openjdk.org  Tue Apr 22 23:20:58 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 22 Apr 2025 23:20:58 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v7]
In-Reply-To: 
References: 
Message-ID: 

> Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead to intermittent test failures ([JDK-8298783](https://bugs.openjdk.org/browse/JDK-8298783)  is a recent example).
> 
> A better mechanism already exists in the private `Reference.waitForReferenceProcessing()` method. This PR makes `waitForReferenceProcessing()` available to tests via the `WhiteBox` and `ForceGC` test libraries.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  catch IllegalAccessException instead of Throwable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24527/files
  - new: https://git.openjdk.org/jdk/pull/24527/files/e47caf5a..8f486e78

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24527&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24527&range=05-06

  Stats: 7 lines in 1 file changed: 2 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24527/head:pull/24527

PR: https://git.openjdk.org/jdk/pull/24527

From bchristi at openjdk.org  Tue Apr 22 23:20:58 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 22 Apr 2025 23:20:58 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v6]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 14 Apr 2025 03:57:41 GMT, Kim Barrett  wrote:

>> test/lib/jdk/test/whitebox/WhiteBox.java line 609:
>> 
>>> 607:       throw e;
>>> 608:     } catch (Throwable t) {
>>> 609:       throw new RuntimeException(t);
>> 
>> The only checked exceptions that are thrown by the try-body are `InvocationTargetException` and
>> `IllegalAccessException` (both from `Method::invoke`).  The way `InvocationTargetException` is being
>> handled here seems fine.  But I think it would be better to explicitly handle `IllegalAccessException` and
>> transform it into a `RuntimeException`, and let everything else just propagate out untouched, e.g. no
>> handlers for `RuntimeException` or `Throwable`.
>
> Thinking about this some more, if we're going to extract and (re)throw
> InterruptedException directly, then I prefer my earlier version:
> https://github.com/openjdk/jdk/pull/24527#pullrequestreview-2755384786

The latest update catches `IllegalAccessException`, and therefore doesn't need to catch `Throwable`, which I agree is nicer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2055011473

From jiangli at openjdk.org  Tue Apr 22 23:29:02 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 22 Apr 2025 23:29:02 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
> 
> `NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.
> 
> In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java
  
  Thanks.
  
  I used `jdk.internal.loader.NativeLibraries` as a quick change before adding adding import. I neglected to to clean up that part.
  
  Co-authored-by: Chen Liang 

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24801/files
  - new: https://git.openjdk.org/jdk/pull/24801/files/7cc1b268..11f674c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24801&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24801&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24801/head:pull/24801

PR: https://git.openjdk.org/jdk/pull/24801

From jiangli at openjdk.org  Tue Apr 22 23:29:02 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 22 Apr 2025 23:29:02 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Apr 2025 21:32:48 GMT, Chen Liang  wrote:

> `sysLookup` does look much cleaner compared to `jdkLibraryPath`.

@liach Thanks for the quick review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2822696068

From liach at openjdk.org  Tue Apr 22 23:31:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 23:31:44 GMT
Subject: RFR: 8354899: Reduce overhead associated with type switches [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Apr 2025 17:20:15 GMT, Chen Liang  wrote:

>> The downcallHandle method in Linker has a complex implementation, and type switches is triggered in multiple places in that handle.
>> 
>> After bytestacks analysis of a simple program that links the native implementation of Class::forName0, it turns out that:
>> 1. there are a few missed usages of type switch in ClassFile API
>> 2. type switch can speed up generation by using explicit stack maps, as stack map gen is over 50% of the generation instructions because the switch is branch-heavy, but the frames are actually simple.
>> 
>> These two combined are not that significant in the overall overhead of downcallHandle, but would be helpful for other workloads.
>
> 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:
> 
>  - Rollback classfile boot speed changes
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/switch-gen-speed
>  - Fix adding potentially unbound labels
>  - 8354899: Reduce overhead associated with type switches

Split the ClassFile API boot safety into #24807.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24705#issuecomment-2822699893

From liach at openjdk.org  Tue Apr 22 23:33:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 23:33:49 GMT
Subject: RFR: 8355335: Avoid pattern matching switches in core ClassFile API
Message-ID: 

A few pattern matching switches exist in the core parts of ClassFile API responsible for transformations and parsing. They are likely to be used in early bootstrap, and pattern matching switches require bootstrap methods, which depend on core ClassFile API.

For example, currently BlockCodeBuilderImpl prevents BlockCodeBuilder from being used in early bootstrap; luckily we are currently all using manual labels, and as a result this does not surface in lambdas.

-------------

Commit messages:
 - 8355335: Avoid pattern matching switches in core ClassFile API

Changes: https://git.openjdk.org/jdk/pull/24807/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24807&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355335
  Stats: 35 lines in 6 files changed: 4 ins; 7 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/24807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24807/head:pull/24807

PR: https://git.openjdk.org/jdk/pull/24807

From ccheung at openjdk.org  Tue Apr 22 23:42:02 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 22 Apr 2025 23:42:02 GMT
Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking [v6]
In-Reply-To: 
References: 
Message-ID: 

> This RFE allows --add-opens to be specified for AOT cache creation. AOT cache can be used during production run with --add-opens option as long as the same set of options is used during assembly phase.
> 
> Passed tiers 1 - 4 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  @AlanBateman suggestion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24695/files
  - new: https://git.openjdk.org/jdk/pull/24695/files/465261f7..0f28e07b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24695&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24695&range=04-05

  Stats: 68 lines in 3 files changed: 8 ins; 30 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/24695.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24695/head:pull/24695

PR: https://git.openjdk.org/jdk/pull/24695

From liach at openjdk.org  Wed Apr 23 00:00:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Apr 2025 00:00:41 GMT
Subject: RFR: 8355335: Avoid pattern matching switches in core ClassFile
 API
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Apr 2025 23:28:38 GMT, Chen Liang  wrote:

> A few pattern matching switches exist in the core parts of ClassFile API responsible for transformations and parsing. They are likely to be used in early bootstrap, and pattern matching switches require bootstrap methods, which depend on core ClassFile API.
> 
> For example, currently BlockCodeBuilderImpl prevents BlockCodeBuilder from being used in early bootstrap; luckily we are currently all using manual labels, and as a result this does not surface in lambdas.

Testing: tier1, tier2

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24807#issuecomment-2822739583

From liach at openjdk.org  Wed Apr 23 00:01:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Apr 2025 00:01:15 GMT
Subject: RFR: 8354877: DirectClassBuilder default flags should include
 ACC_SUPER
Message-ID: <0ranEoj50aTeRbxcIKrpenUwkjCFQdkRzixtS7CvFiY=.56a42ff8-bd0c-471b-9779-606a804391b9@github.com>

In the future value objects JEP, class files must have one of ACC_IDENTITY (now ACC_SUPER), ACC_ABSTRACT, and ACC_FINAL bits set, otherwise they are rejected. The current default flag has none of these bits set, meaning that it will not be suitable in the future. Currently, most class file generation in the JDK explicitly set ACC_SUPER for compatibility; we should also set this bit in the default flags, despite being no-op, in anticipation of future compatibility.

The API specifications of ClassBuilder and AccessFlags already state that an unspecified default flag for class builders are chosen, so changing this flag should be fine without extra specification changes.

-------------

Commit messages:
 - 8354877: DirectClassBuilder default flags should include ACC_SUPER

Changes: https://git.openjdk.org/jdk/pull/24808/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24808&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354877
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24808/head:pull/24808

PR: https://git.openjdk.org/jdk/pull/24808

From liach at openjdk.org  Wed Apr 23 00:01:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Apr 2025 00:01:15 GMT
Subject: RFR: 8354877: DirectClassBuilder default flags should include
 ACC_SUPER
In-Reply-To: <0ranEoj50aTeRbxcIKrpenUwkjCFQdkRzixtS7CvFiY=.56a42ff8-bd0c-471b-9779-606a804391b9@github.com>
References: <0ranEoj50aTeRbxcIKrpenUwkjCFQdkRzixtS7CvFiY=.56a42ff8-bd0c-471b-9779-606a804391b9@github.com>
Message-ID: 

On Tue, 22 Apr 2025 23:55:54 GMT, Chen Liang  wrote:

> In the future value objects JEP, class files must have one of ACC_IDENTITY (now ACC_SUPER), ACC_ABSTRACT, and ACC_FINAL bits set, otherwise they are rejected. The current default flag has none of these bits set, meaning that it will not be suitable in the future. Currently, most class file generation in the JDK explicitly set ACC_SUPER for compatibility; we should also set this bit in the default flags, despite being no-op, in anticipation of future compatibility.
> 
> The API specifications of ClassBuilder and AccessFlags already state that an unspecified default flag for class builders are chosen, so changing this flag should be fine without extra specification changes.

Testing: tier 1-3

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24808#issuecomment-2822739694

From liach at openjdk.org  Wed Apr 23 00:21:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Apr 2025 00:21:05 GMT
Subject: RFR: 8342206: Convenience method to check if a constant pool entry
 matches nominal descriptors [v2]
In-Reply-To: 
References: 
Message-ID: 

> The ClassFile API promotes usage of constant nominal descriptors over literal strings. However, for `class` file parsing, currently the efficient way to check if a constant pool entry matches a desired descriptor is via unrolling them back to strings. However, string unrolling is ugly, and often times confusing, such as internal names versus field descriptors.
> 
> As a result, I propose to provide new methods that compare constant pool entries with the potential symbolic descriptors they represent. This is no less efficient as checking raw string equality, avoids exceptional failure behaviors of conversion to symbolic descriptors, and avoids potential programmer errors stemming from raw string handling. See the CSR for a full story.

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:

 - Rename UTF8 test methods to be different from other test methods
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cf-equals-sym
 - 8342206: Convenience method to check if a constant pool entry matches nominal descriptors

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23548/files
  - new: https://git.openjdk.org/jdk/pull/23548/files/4e73380c..dd3adbc9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23548&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23548&range=00-01

  Stats: 450585 lines in 6096 files changed: 149618 ins; 269944 del; 31023 mod
  Patch: https://git.openjdk.org/jdk/pull/23548.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23548/head:pull/23548

PR: https://git.openjdk.org/jdk/pull/23548

From liach at openjdk.org  Wed Apr 23 00:21:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Apr 2025 00:21:05 GMT
Subject: RFR: 8342206: Convenience method to check if a constant pool entry
 matches nominal descriptors
In-Reply-To: 
References: 
Message-ID: <5i6Ny2JFTJHSt6QC8eyiNPU5oBdkGWellQ3UGiBfWIw=.878d04a7-aab5-4fce-91c3-6bb140031f81@github.com>

On Tue, 11 Feb 2025 02:26:57 GMT, Chen Liang  wrote:

> The ClassFile API promotes usage of constant nominal descriptors over literal strings. However, for `class` file parsing, currently the efficient way to check if a constant pool entry matches a desired descriptor is via unrolling them back to strings. However, string unrolling is ugly, and often times confusing, such as internal names versus field descriptors.
> 
> As a result, I propose to provide new methods that compare constant pool entries with the potential symbolic descriptors they represent. This is no less efficient as checking raw string equality, avoids exceptional failure behaviors of conversion to symbolic descriptors, and avoids potential programmer errors stemming from raw string handling. See the CSR for a full story.

I have updated to rename other methods as `matches`, and the utf8 ones `isFieldType` and `isMethodType`. These should avoid ambiguities with `ClassEntry`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23548#issuecomment-2822761127

From bchristi at openjdk.org  Wed Apr 23 00:23:57 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 23 Apr 2025 00:23:57 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v8]
In-Reply-To: 
References: 
Message-ID: 

> Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead to intermittent test failures ([JDK-8298783](https://bugs.openjdk.org/browse/JDK-8298783)  is a recent example).
> 
> A better mechanism already exists in the private `Reference.waitForReferenceProcessing()` method. This PR makes `waitForReferenceProcessing()` available to tests via the `WhiteBox` and `ForceGC` test libraries.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  make waitForReferenceProcessingMethod volatile

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24527/files
  - new: https://git.openjdk.org/jdk/pull/24527/files/8f486e78..316800ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24527&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24527&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24527/head:pull/24527

PR: https://git.openjdk.org/jdk/pull/24527

From henryjen at openjdk.org  Wed Apr 23 00:27:42 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 23 Apr 2025 00:27:42 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Apr 2025 23:29:02 GMT, Jiangli Zhou  wrote:

>> Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
>> 
>> `NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.
>> 
>> In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java
>   
>   Thanks.
>   
>   I used `jdk.internal.loader.NativeLibraries` as a quick change before adding adding import. I neglected to to clean up that part.
>   
>   Co-authored-by: Chen Liang 

src/java.base/share/native/libsyslookup/syslookup.c line 30:

> 28: #include 
> 29: 
> 30: #include 

Do we need this include? DEF_STATIC_JNI_OnLoad is defined by jni_util.h, which should include jni.h?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24801#discussion_r2055074496

From vlivanov at openjdk.org  Wed Apr 23 00:40:04 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 23 Apr 2025 00:40:04 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v11]
In-Reply-To: 
References: 
Message-ID: 

> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
> 
> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
> 
> The patch consists of the following parts:
>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
> 
> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
> 
> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
> 
> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
> 
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
> 
> Thanks!

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  riscv fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24462/files
  - new: https://git.openjdk.org/jdk/pull/24462/files/88eacc48..3d1adff2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=09-10

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24462/head:pull/24462

PR: https://git.openjdk.org/jdk/pull/24462

From vlivanov at openjdk.org  Wed Apr 23 00:40:04 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 23 Apr 2025 00:40:04 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v10]
In-Reply-To: 
References: 
 
 
 
Message-ID: <4c9BdDJr1BWA92Uv7HHIa6_ons9yzW0U6q0uOzKLxPY=.102b7ec5-c4bb-4117-a092-0815d01aa74d@github.com>

On Tue, 22 Apr 2025 16:46:44 GMT, Hamlin Li  wrote:

>> src/hotspot/share/runtime/abstract_vm_version.cpp line 349:
>> 
>>> 347:   assert(features_offset <= cpu_info_string_len, "");
>>> 348:   if (features_offset < cpu_info_string_len) {
>>> 349:     assert(cpu_info_string[features_offset + 0] == ',', "");
>> 
>> This assert fails on riscv.
>
> A simple fix could be:
> 
> diff --git a/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp b/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp
> index 484a2a645aa..a785dc65c9e 100644
> --- a/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp
> +++ b/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp
> @@ -196,25 +196,12 @@ void VM_Version::setup_cpu_available_features() {
>  
>    _cpu_info_string = os::strdup(buf);
>  
> -  _features_string = extract_features_string(_cpu_info_string,
> -                                             strnlen(_cpu_info_string, sizeof(buf)),
> -                                             features_offset);
> +  _features_string = _cpu_info_string;
>  }

Alternatively, it's fine for now to completely drop `extract_features_string` call on linux-riscv  (as on some other platforms) and fix it separately. Then `VectorSupport.getCPUFeatures()` returns empty string. `VectorMathLibrary` doesn't rely on `CPUFeatures` on RISC-V.

Let me know how you prefer to handle it.

>> src/hotspot/share/runtime/abstract_vm_version.hpp line 61:
>> 
>>> 59:   static const char* _features_string;
>>> 60: 
>>> 61:   static const char* _cpu_info_string;
>> 
>> Not quite sure the reason to introduce `_cpu_info_string`.
>> Seems to me you could just use _features_string, and remove _cpu_info_string and its related code, e.g. `extract_features_string`. Please check the code in `test/lib/jdk/test/whitebox/cpuinfo/CPUInfo.java`
>
> Mayber in `CPUFeatures`, could use the similar code as `CPUInfo` to split the cpu string into cpu features?

The intention is to align `_features_string` with `_features` which enumerates well-known CPU capabilities JVM manages. As of now, `_features_string` contains more information, so I introduced `_cpu_info_string` to keep it.

Speaking of `test/lib/jdk/test/whitebox/cpuinfo/CPUInfo.java`, the approach chosen there may be fine for a test library, but we need a more stable API between JVM and JDK.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2055073587
PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2055071408

From vlivanov at openjdk.org  Wed Apr 23 00:40:07 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 23 Apr 2025 00:40:07 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v10]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 22 Apr 2025 13:45:26 GMT, Hamlin Li  wrote:

>> Vladimir Ivanov 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 24 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into vector.math.01.java
>>  - RVV and SVE adjustments
>>  - fix broken merge
>>  - Merge branch 'master' into vector.math.01.java
>>  - Fix debugName handling
>>  - Merge branch 'master' into vector.math.01.java
>>  - RVV and SVE adjustments
>>  - Merge branch 'master' into vector.math.01.java
>>  - Fix windows-aarch64 build failure
>>  - features_string -> cpu_info_string
>>  - ... and 14 more: https://git.openjdk.org/jdk/compare/41f2363b...88eacc48
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/CPUFeatures.java line 82:
> 
>> 80:         return features;
>> 81:     }
>> 82: }
> 
> Maybe an extra line needed at the end of this file?

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2055072426

From vlivanov at openjdk.org  Wed Apr 23 00:40:07 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 23 Apr 2025 00:40:07 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v10]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 22 Apr 2025 14:46:21 GMT, Ludovic Henry  wrote:

>> Vladimir Ivanov 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 24 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into vector.math.01.java
>>  - RVV and SVE adjustments
>>  - fix broken merge
>>  - Merge branch 'master' into vector.math.01.java
>>  - Fix debugName handling
>>  - Merge branch 'master' into vector.math.01.java
>>  - RVV and SVE adjustments
>>  - Merge branch 'master' into vector.math.01.java
>>  - Fix windows-aarch64 build failure
>>  - features_string -> cpu_info_string
>>  - ... and 14 more: https://git.openjdk.org/jdk/compare/41f2363b...88eacc48
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 75:
> 
>> 73:             return switch (StaticProperty.osArch()) {
>> 74:                 case "amd64", "x86_64" -> SVML;
>> 75:                 case "aarch64" -> SLEEF;
> 
> We should be supporting SLEEF on `riscv64`. Was there a specific motivation not to include it here?

Goot catch, fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2055072456

From vlivanov at openjdk.org  Wed Apr 23 00:49:50 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 23 Apr 2025 00:49:50 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v10]
In-Reply-To: 
References: 
 
 
Message-ID: <5_VO9Man5zVU0MPXJK9lkxmh5w58zZ1k4DhLdZQEz9w=.16f2054a-ef90-4c8a-a3ef-c2ee758643a2@github.com>

On Fri, 18 Apr 2025 16:16:28 GMT, Jorn Vernee  wrote:

>> Vladimir Ivanov 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 24 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into vector.math.01.java
>>  - RVV and SVE adjustments
>>  - fix broken merge
>>  - Merge branch 'master' into vector.math.01.java
>>  - Fix debugName handling
>>  - Merge branch 'master' into vector.math.01.java
>>  - RVV and SVE adjustments
>>  - Merge branch 'master' into vector.math.01.java
>>  - Fix windows-aarch64 build failure
>>  - features_string -> cpu_info_string
>>  - ... and 14 more: https://git.openjdk.org/jdk/compare/685357bf...88eacc48
>
> src/hotspot/share/prims/vectorSupport.cpp line 622:
> 
>> 620: 
>> 621:   ThreadToNativeFromVM ttn(thread);
>> 622:   return env->NewStringUTF(features_string);
> 
> Isn't there a way to do this without the extra transition?
> 
> How about:
> 
> 
>   oop result = java_lang_String::create_oop_from_str((char*) bytes, CHECK_NULL);
>   return (jstring) JNIHandles::make_local(THREAD, result);

Fair enough.

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 272:
> 
>> 270:                 MemorySegment addr = LOOKUP.findOrThrow(symbol);
>> 271:                 debug("%s %s => 0x%016x\n", op, symbol, addr.address());
>> 272:                 T impl = implSupplier.apply(opc); // TODO: should call the very same native implementation eventually (once FFM API supports vectors)
> 
> FWIW, one current barrier I see to implementing the vector calling convention in the linker, is that the FFM linker (currently) transmits register values to the downcall stub use Java primitive types. So, in order to support vector calling conventions, we would need to add some kind of 'primitive' that can hold the entire vector value, and preferably gets passed in the right register.
> 
> However, I think in the case of these math libraries in particular, speed of the fallback implementation is not that much of an issue, since there is also an intrinsic. So alternatively, we could split a vector value up into smaller integral types (`int`, `long`) -> pass them to the downcall stub in that form -> and then reconstruct the full vector value in its target register. (I used the same trick when I was experimenting with FP80 support, which also requires splitting up the 80 bit value up into 2 `long`s).

IMO an in-memory representation for vectors is preferred when it comes to FFM linker calling conventions. 512-bit vector requires 8 longs, so some of them will end up passed on stack for any non-trivial case. And with in-memory representation, VM can elide vector store/load once FFM linker stub is intrinsified.

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 305:
> 
>> 303:     @ForceInline
>> 304:     /*package-private*/ static
>> 305:     >
> 
> Here you're using `Vector` instead of `VectorPayload` for the binary op, so there seems to be a discrepancy with `VectorSupport`.

I don't have a strong preference, but I kept it aligned with `unaryOp`/`binaryOp` intrinsics.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2055086616
PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2055086145
PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2055087281

From jiangli at openjdk.org  Wed Apr 23 00:56:18 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 23 Apr 2025 00:56:18 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: 
References: 
Message-ID: <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>

> Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
> 
> `NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.
> 
> In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.

Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
 - Address henryjen@ comment:
   - Remove '#include '.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24801/files
  - new: https://git.openjdk.org/jdk/pull/24801/files/11f674c6..6661b815

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24801&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24801&range=01-02

  Stats: 3 lines in 3 files changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24801/head:pull/24801

PR: https://git.openjdk.org/jdk/pull/24801

From jiangli at openjdk.org  Wed Apr 23 00:56:18 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 23 Apr 2025 00:56:18 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 23 Apr 2025 00:24:55 GMT, Henry Jen  wrote:

> Do we need this include? DEF_STATIC_JNI_OnLoad is defined by jni_util.h, which should include jni.h?

Removed, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24801#discussion_r2055090726

From swen at openjdk.org  Wed Apr 23 00:58:08 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 23 Apr 2025 00:58:08 GMT
Subject: RFR: 8355301: Simplify the code by using record [v2]
In-Reply-To: 
References: 
Message-ID: 

> As the title says, this is a simple refactoring that simplifies the code by using record.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  from @liach, Use static pirntln method to replace WrappedStream and WrappedPrintWriter

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24795/files
  - new: https://git.openjdk.org/jdk/pull/24795/files/6f7b62bc..1f932b2d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24795&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24795&range=00-01

  Stats: 61 lines in 1 file changed: 13 ins; 32 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/24795.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24795/head:pull/24795

PR: https://git.openjdk.org/jdk/pull/24795

From vlivanov at openjdk.org  Wed Apr 23 01:02:19 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 23 Apr 2025 01:02:19 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v12]
In-Reply-To: 
References: 
Message-ID: 

> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
> 
> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
> 
> The patch consists of the following parts:
>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
> 
> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
> 
> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
> 
> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
> 
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
> 
> Thanks!

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Avoid thread state transition in VectorSupport_GetCPUFeatures

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24462/files
  - new: https://git.openjdk.org/jdk/pull/24462/files/3d1adff2..42ed9baa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=10-11

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24462/head:pull/24462

PR: https://git.openjdk.org/jdk/pull/24462

From duke at openjdk.org  Wed Apr 23 01:11:40 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 23 Apr 2025 01:11:40 GMT
Subject: RFR: 8355301: Simplify the code by using record [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 00:58:08 GMT, Shaojin Wen  wrote:

>> As the title says, this is a simple refactoring that simplifies the code by using record.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   from @liach, Use static pirntln method to replace WrappedStream and WrappedPrintWriter

The?shared implementation?method either?needs to?be?renamed, or?the?parameter needs?to?be?cast to?`Object`, as?otherwise this?ll just?lead to?infinite self?recursion.

src/java.base/share/classes/java/lang/Throwable.java line 689:

> 687:     }
> 688: 
> 689:     private void printStackTrace(Object printer) {

Suggestion:

        printStackTrace0(s);
    }

    private void printStackTrace0(Object printer) {

src/java.base/share/classes/java/lang/Throwable.java line 776:

> 774:      */
> 775:     public void printStackTrace(PrintWriter s) {
> 776:         printStackTrace(s);

Suggestion:

        printStackTrace0(s);

-------------

Changes requested by ExE-Boss at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/24795#pullrequestreview-2785712763
PR Review Comment: https://git.openjdk.org/jdk/pull/24795#discussion_r2055099442
PR Review Comment: https://git.openjdk.org/jdk/pull/24795#discussion_r2055099540

From jpai at openjdk.org  Wed Apr 23 01:13:39 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 23 Apr 2025 01:13:39 GMT
Subject: RFR: 8354898: jdk/internal/loader/NativeLibraries/Main.java fails
 on static JDK
In-Reply-To: 
References: 
Message-ID: 

On Wed, 16 Apr 2025 23:41:40 GMT, Jiangli Zhou  wrote:

> Please review this simple test change that skips the test case loading using JDK `libzip.so` on static JDK in test/jdk/jdk/internal/loader/NativeLibraries/Main.java. AFAICT, the test case using `NativeLibrariesTest.LIB_NAME` (`libnativeLibrariesTest.so`) can provide coverage on static JDK.
> 
> Thanks

Marked as reviewed by jpai (Reviewer).

Thank you Jiangli for the details in the JBS issue. That helped. Having read the documentation of `jdk.internal.loader.RawNativeLibraries` yesterday:


 * RawNativeLibraries has the following properties:
 * 1. Native libraries loaded in this RawNativeLibraries instance are
 *    not JNI native libraries.  Hence JNI_OnLoad and JNI_OnUnload will
 *    be ignored.  No support for linking of native method.
 ```

I mistook that it cannot be used to load JNI libraries and that's what confused me about this test since `libzip` is a JNI library. But reading this text again, I now realize that it can be used to load a JNI native library, but the loaded library won't be treated as a JNI library by `RawNativeLibraries`. So the usage of `libzip` in that test seems OK. I further looked at the change which introduced this usage in that test to understand if it was intentional to use a JNI library here. It appears that it was introduced in https://bugs.openjdk.org/browse/JDK-8281335 and so was an intentional decision to use a JNI library.

Given all this, I think the proposal to skip this loading for static JDK seems reasonable to me.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24704#pullrequestreview-2785715732
PR Comment: https://git.openjdk.org/jdk/pull/24704#issuecomment-2822818016

From jpai at openjdk.org  Wed Apr 23 01:13:40 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 23 Apr 2025 01:13:40 GMT
Subject: RFR: 8354898: jdk/internal/loader/NativeLibraries/Main.java fails
 on static JDK
In-Reply-To: 
References: 
 <68U_vj5WY81keMaVqgpGwGWjvOEfBhIcR1kpf_noOgk=.49e2b7b2-9a0c-4187-b702-cf3cb5b1255d@github.com>
 
Message-ID: 

On Tue, 22 Apr 2025 20:36:12 GMT, Jiangli Zhou  wrote:

> I also added command line examples for building static-jdk and the current method for running jtreg tests on static-jdk.

Thank you, that will help me in future.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24704#issuecomment-2822819479

From swen at openjdk.org  Wed Apr 23 01:24:15 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 23 Apr 2025 01:24:15 GMT
Subject: RFR: 8355301: Simplify the code by using record [v3]
In-Reply-To: 
References: 
Message-ID: 

> As the title says, this is a simple refactoring that simplifies the code by using record.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  bug fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24795/files
  - new: https://git.openjdk.org/jdk/pull/24795/files/1f932b2d..df2d6153

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24795&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24795&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24795.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24795/head:pull/24795

PR: https://git.openjdk.org/jdk/pull/24795

From swen at openjdk.org  Wed Apr 23 01:31:56 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 23 Apr 2025 01:31:56 GMT
Subject: RFR: 8355301: Simplify the code by using record [v4]
In-Reply-To: 
References: 
Message-ID: <2FArm3JRh9gez7hXK0J3YS8U5tgVTCGxdd0y1qq1cLw=.9593786d-27dd-4bd7-819d-1cd4c125d0bd@github.com>

> As the title says, this is a simple refactoring that simplifies the code by using record.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  printStackTrace0

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24795/files
  - new: https://git.openjdk.org/jdk/pull/24795/files/df2d6153..b9050803

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24795&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24795&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24795.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24795/head:pull/24795

PR: https://git.openjdk.org/jdk/pull/24795

From naoto at openjdk.org  Wed Apr 23 01:37:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 23 Apr 2025 01:37:50 GMT
Subject: RFR: 8350703: Add standard system property stdin.encoding
In-Reply-To: 
References: 
Message-ID: 

On Thu, 17 Apr 2025 18:59:33 GMT, Stuart Marks  wrote:

> * Windows and Unix: set sprops.stdin_encoding if connected to a console
> * Add specs for stdin.encoding
> * Adjust specs to change "undefined" to "unspecified"
> * Rewrite System.in spec to refer to new property and to clarify usage with classes that perform encoding
> * Update property test

Looks good. Is a corresponding CSR being drafted?

src/java.base/share/classes/jdk/internal/util/SystemProps.java line 92:

> 90: 
> 91:         // Encoding properties for stdin, stdout, and stderr. For stdout and stderr,
> 92:         // check "sun.*.encoding" properties before falling back to the

Could explain about sun* a bit more (just for compatibility) and stdin.encoding is free from it.

src/java.base/windows/native/libjava/java_props_md.c line 637:

> 635: 
> 636:         {
> 637:             HANDLE hStdIn;

Instead of creating a new variable, `hStdOutErr` could be reused with a proper name.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24738#pullrequestreview-2785735700
PR Review Comment: https://git.openjdk.org/jdk/pull/24738#discussion_r2055115841
PR Review Comment: https://git.openjdk.org/jdk/pull/24738#discussion_r2055116403

From asemenyuk at openjdk.org  Wed Apr 23 02:30:59 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 23 Apr 2025 02:30:59 GMT
Subject: RFR: 8355328: Improve negative tests coverage for jpackage signing
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Add tests covering `error.explicit-sign-no-cert` error ID to ErrorTest.
> 
> If signing identity validation fails, jpackage outputs three messages constructed from the following string IDs: `error.cert.not.found`, `error.explicit-sign-no-cert`, and `error.explicit-sign-no-cert.advice`.
> 
> `TKit.TextStreamVerifier.andThen()` method doesn't work correctly when combining more than two instances of `TKit.TextStreamVerifier` class. To address this bug and analyze jpackage's output for three expected strings when a non-existent signing identity is specified, the `TKit.TextStreamVerifier.andThen()` method was replaced with the `TKit.TextStreamVerifier.Group` class. Changes in other tests are a result of this change.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Fix whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24786/files
  - new: https://git.openjdk.org/jdk/pull/24786/files/a57b5d8a..8d3d9b5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24786&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24786&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24786.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24786/head:pull/24786

PR: https://git.openjdk.org/jdk/pull/24786

From asemenyuk at openjdk.org  Wed Apr 23 02:30:59 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 23 Apr 2025 02:30:59 GMT
Subject: RFR: 8355328: Improve negative tests coverage for jpackage signing
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Apr 2025 21:48:16 GMT, Alexander Matveev  wrote:

>> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix whitespace
>
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java line 982:
> 
>> 980:             createException = other.createException;
>> 981:             anotherVerifier = other.anotherVerifier;
>> 982:             value= other.value;
> 
> Space before =.

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24786#discussion_r2055151735

From swen at openjdk.org  Wed Apr 23 02:35:54 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 23 Apr 2025 02:35:54 GMT
Subject: Integrated: 8355240: Remove unused Import in StringUTF16
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Apr 2025 03:35:03 GMT, Shaojin Wen  wrote:

> This PR is to remove unused imports after PR #16425

This pull request has now been integrated.

Changeset: bc518a6c
Author:    Shaojin Wen 
URL:       https://git.openjdk.org/jdk/commit/bc518a6cbb9fadc47b00239b4d721c1c62dc5dad
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8355240: Remove unused Import in StringUTF16

Reviewed-by: rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/24788

From liach at openjdk.org  Wed Apr 23 03:22:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Apr 2025 03:22:52 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console() [v4]
In-Reply-To: 
References: 
 
Message-ID: <0hSBVgWTTcbmEF1OQVVptjzsahPiyRNkQi1cbpLuTC8=.ee19f511-c795-48ee-8bf3-0d4987934d23@github.com>

On Wed, 16 Apr 2025 12:07:45 GMT, Jan Lahoda  wrote:

>> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell.
>> 
>> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend.
>> 
>> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback: Adding makefile comment as suggested

src/java.base/share/classes/jdk/internal/io/BaseJdkConsoleImpl.java line 175:

> 173:     protected final Charset charset;
> 174:     protected final Object readLock;
> 175:     protected final Object writeLock;

Recommend mentioning that when both locks must be acquired, the `writeLock` must be acquired first. Unfortunately we cannot just use a `ReentrantReadWriteLock`.

src/java.base/share/classes/jdk/internal/io/BaseJdkConsoleImpl.java line 181:

> 179:     protected final Formatter formatter;
> 180: 
> 181:     protected abstract char[] readline(boolean password) throws IOException;

I recommend a more distinct method name, like `nextLine` or `implReadLine`; using `readline` to distinguish from `readLine` is weird.

src/java.base/share/classes/jdk/internal/io/BaseJdkConsoleImpl.java line 184:

> 182: 
> 183:     @SuppressWarnings("this-escape")
> 184:     public BaseJdkConsoleImpl(Charset charset) {

Suggestion:

    protected BaseJdkConsoleImpl(Charset charset) {

src/jdk.internal.le/share/classes/jdk/internal/console/JdkConsoleImpl.java line 38:

> 36:  * JdkConsole implementation based on the platform's TTY, with basic keyboard navigation.
> 37:  */
> 38: public final class JdkConsoleImpl extends BaseJdkConsoleImpl {

We should choose a different simple name for this class, especially when we are importing classes from `jdk.internal.io` package.

src/jdk.internal.le/share/classes/jdk/internal/console/JdkConsoleImpl.java line 57:

> 55:     }
> 56: 
> 57:     protected char[] readline(boolean password) throws IOException {

`@Override`

src/jdk.internal.le/share/classes/jdk/internal/console/LastErrorException.java line 28:

> 26: 
> 27: @SuppressWarnings("serial")
> 28: public class LastErrorException extends RuntimeException{

Suggestion:

public class LastErrorException extends RuntimeException {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2055177151
PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2055179038
PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2055177261
PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2055183690
PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2055181215
PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2055181573

From kbarrett at openjdk.org  Wed Apr 23 06:13:01 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 23 Apr 2025 06:13:01 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v8]
In-Reply-To: 
References: 
 
Message-ID: <8SJQ-BKC1er-93wOIx-u4NZXx5f5XAqzirLqIYhwDNk=.11200bdd-f6fe-45fb-919e-410a6e7e6ae9@github.com>

On Wed, 23 Apr 2025 00:23:57 GMT, Brent Christian  wrote:

>> Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead to intermittent test failures ([JDK-8298783](https://bugs.openjdk.org/browse/JDK-8298783)  is a recent example).
>> 
>> A better mechanism already exists in the private `Reference.waitForReferenceProcessing()` method. This PR makes `waitForReferenceProcessing()` available to tests via the `WhiteBox` and `ForceGC` test libraries.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make waitForReferenceProcessingMethod volatile

A couple of lingering comments that may or may not result in changes, but
otherwise looks good to me.

test/lib/jdk/test/whitebox/WhiteBox.java line 598:

> 596:       Method wfrp = getWaitForReferenceProcessingMethod();
> 597:       return (Boolean) wfrp.invoke(null);
> 598:     } catch (IllegalAccessException t) {

s/t/e/ ?  `t` seems to be leftover from when the version that was catching a Throwable.

test/lib/jdk/test/whitebox/WhiteBox.java line 605:

> 603:         throw (InterruptedException) cause;
> 604:       } else {
> 605:         throw new RuntimeException(e);

I still think it would be better to finish unwrapping e, rather than further
wrapping it. We know the only checked exception is InterruptedException,
because we checked that when looking up the method. That leaves either
RuntimeException or Error. I think it is generally inappropriate to wrap
Errors, and we don't really need to additionally wrap the RuntimeException
case. But I'm going to approve this change anyway, and leave that question to
real Java programmers.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24527#pullrequestreview-2786037305
PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2055313446
PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2055314679

From jwaters at openjdk.org  Wed Apr 23 06:18:50 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 23 Apr 2025 06:18:50 GMT
Subject: RFR: 8342868: Errors related to unused code on Windows after
 8339120 in core libs [v2]
In-Reply-To: 
References: 
 
Message-ID: <3LBsjxpWNEAajok5P7-DTOKRKkUmGmyjudWTWlshZ64=.3780c643-dd12-489f-a237-cc3b32b642e0@github.com>

On Thu, 31 Oct 2024 05:43:11 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
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the got local

Stay open

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21654#issuecomment-2823181043

From alan.bateman at oracle.com  Wed Apr 23 06:37:18 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Wed, 23 Apr 2025 07:37:18 +0100
Subject: The virtual thread is not parked in InetAddress isReachable
In-Reply-To: 
References: 
 
 
Message-ID: <7b431f76-3a98-4c8c-8e01-ab44710f3b35@oracle.com>

On 22/04/2025 14:28, Anton Rameykov wrote:
> Alan, good day to you. I have a few questions. Could you please advise 
> me to forward my initial message to the net-dev mailing list? Sorry, 
> it's just my first time with the mailing model. And second question, 
> if the thread went to native code why Djdk.tracePinnedThreads=full 
> didn't work and didn't show debugging information.
>
The diagnostic option that used to be enabled with 
-Djdk.tracePinnedThreads=full was limited to cases where a virtual 
thread parked in Java while pinned. The scenario with 
InetAddress.isReachable is that it is implemented in native code so 
doesn't integrate with the diagnostics features that report pinning. The 
right thing here is to re-implement InetAddress.isReachable, it's just 
hasn't been high priority to do that.

-Alan

From alanb at openjdk.org  Wed Apr 23 06:46:41 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Apr 2025 06:46:41 GMT
Subject: RFR: 8355301: Simplify Throwable::printStackTrace by replacing
 inner class with static method [v4]
In-Reply-To: <2FArm3JRh9gez7hXK0J3YS8U5tgVTCGxdd0y1qq1cLw=.9593786d-27dd-4bd7-819d-1cd4c125d0bd@github.com>
References: 
 <2FArm3JRh9gez7hXK0J3YS8U5tgVTCGxdd0y1qq1cLw=.9593786d-27dd-4bd7-819d-1cd4c125d0bd@github.com>
Message-ID: 

On Wed, 23 Apr 2025 01:31:56 GMT, Shaojin Wen  wrote:

>> The current Throwable::printStackTrace implementation uses three inner classes PrintStreamOrWriter/WrappedPrintStream/WrappedPrintWriter. We can introduce a static method println to replace these three embedded classes.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   printStackTrace0

src/java.base/share/classes/java/lang/Throwable.java line 689:

> 687:     }
> 688: 
> 689:     private void printStackTrace0(Object printer) {

Ugh, hopefully this will be replaced in the next iteration.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24795#discussion_r2055363102

From duke at openjdk.org  Wed Apr 23 06:51:58 2025
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Wed, 23 Apr 2025 06:51:58 GMT
Subject: RFR: 8352016: Improve
 java/lang/RuntimeTests/RuntimeExitLogTest.java
In-Reply-To: 
References: 
 
Message-ID: <0_a_W4-l3eD__HK9n11b9gv2K38V68iRDIADajqx99w=.3cc19192-0a21-4e5d-bc5f-5ae38cd891bd@github.com>

On Wed, 19 Mar 2025 20:07:26 GMT, Roger Riggs  wrote:

>> The current test program for the logging feature added in JDK-8301627 does not fully check some important cases.
>> 
>> Issue Details:
>> The test does not properly check cases where logging might not happen due to different logging levels. (e.g. ALL, TRACE, WARNING, etc.)
>> The check for the logged stack trace is not enough, as it does not confirm enough details in the output.
>> 
>> Fix Details:
>> Added more test cases to check behavior under different logging levels.
>> Improved the stack trace check by verifying more details in the logged output.
>> These changes make the test more complete and ensure that the logging feature works as expected.
>> Also, any existing test cases prior to this pull request are retained.
>> 
>> The test was verified in the following OS environments, and it passed successfully in both environments.
>> - Windows Server 2022 Standard 21H2
>> - Red Hat Enterprise Linux release 9.2 (Plow)
>> 
>> Could you please review this fix?
>
> Out of curiosity, what raised this as an issue that needed more tests? 
> Was there a failure of some implementation that caused a bug?

Hi, @RogerRiggs 
I have answered some of your comments. Could you please take another look?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24050#issuecomment-2823243699

From duke at openjdk.org  Wed Apr 23 07:25:50 2025
From: duke at openjdk.org (duke)
Date: Wed, 23 Apr 2025 07:25:50 GMT
Subject: Withdrawn: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and
 parseLong
In-Reply-To: 
References: 
Message-ID: 

On Sat, 4 Jan 2025 10:24:15 GMT, Shaojin Wen  wrote:

> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes:
> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3.
> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1.
> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/22919

From pminborg at openjdk.org  Wed Apr 23 07:41:36 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 23 Apr 2025 07:41:36 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v73]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove section on fun/coll sync

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/f9d423de..1a25b863

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=72
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=71-72

  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From vklang at openjdk.org  Wed Apr 23 07:41:37 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 23 Apr 2025 07:41:37 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33]
In-Reply-To: 
References: 
 
 
 <3arhaBIc5A-NbGpFZ_ehEMQhTzXSeIlel9cFNWwg9gE=.a1f457a0-ed07-4016-82ea-bace156ff4e9@github.com>
 
 
Message-ID: 

On Fri, 18 Apr 2025 14:17:37 GMT, Jorn Vernee  wrote:

>> I'm definitely not an expert here, so I'll defer to someone more knowledgable :)
>
> I asked around/looked this up, and it seems 'contents' would be more correct here, since a StableValue is primarily a container of things (you put things into it, get things out).

Yeah, that was what I was thinking too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2055440418

From vklang at openjdk.org  Wed Apr 23 07:45:10 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 23 Apr 2025 07:45:10 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v72]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Apr 2025 15:09:49 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformat docs

src/java.base/share/classes/java/lang/StableValue.java line 457:

> 455:      * @param content to set
> 456:      * @throws IllegalStateException if a supplier invoked by {@link #orElseSet(Supplier)}
> 457:      *         recursively attempts to set this stable value by calling this method.

@minborg Would this be clearer if it said "recursively attempts to set this stable value by calling this method directly or indirectly." ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2055447587

From jpai at openjdk.org  Wed Apr 23 07:58:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 23 Apr 2025 07:58:01 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <9Sltn-rHaM-4yCCjxAV52Wuc2-j-Q6brdwZyP30551c=.6de1542e-d123-4b37-a199-7675c5c1d2f2@github.com>
References: 
 <9Sltn-rHaM-4yCCjxAV52Wuc2-j-Q6brdwZyP30551c=.6de1542e-d123-4b37-a199-7675c5c1d2f2@github.com>
Message-ID: 

On Tue, 22 Apr 2025 16:10:19 GMT, Artur Barashev  wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement 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.
>
> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 366:
> 
>> 364:     }
>> 365: 
>> 366:     public String chooseServerAlias(String keyType,
> 
> This method should have default (package-private) access modifier.

Hello Artur, you are right. This is an overisght and we'll fix this as part of the next refresh of this PR.

> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 375:
> 
>> 373:     }
>> 374: 
>> 375:     public String chooseClientAlias(String[] keyTypes, Principal[] issuers,
> 
> Same as above, the method shouldn't be public.

Agreed. We will address this in the next refresh of the PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2055469463
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2055470483

From jpai at openjdk.org  Wed Apr 23 08:02:02 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 23 Apr 2025 08:02:02 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Apr 2025 18:56:19 GMT, Artur Barashev  wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement 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.
>
> test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 95:
> 
>> 93:         //System.setProperty("javax.net.ssl.keyStorePassword", PASSWORD);
>> 94:         //System.setProperty("javax.net.ssl.trustStore", KEYSTORE);
>> 95:         //System.setProperty("javax.net.ssl.trustStorePassword", PASSWORD);
> 
> Why we don't delete this?

This looks like a leftover. I'll remove this as part of the next refresh.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2055478076

From jpai at openjdk.org  Wed Apr 23 08:05:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 23 Apr 2025 08:05:53 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: 
References: 
 <9rWMdJ_KuW5Auws9DtD_pOWt2Mb4-nGLBDmN0DLFA_0=.c8106398-609d-482d-a5bf-b8b78bb8144d@github.com>
 
Message-ID: 

On Tue, 22 Apr 2025 19:11:24 GMT, Artur Barashev  wrote:

>> test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 96:
>> 
>>> 94:         //System.setProperty("javax.net.ssl.trustStore", KEYSTORE);
>>> 95:         //System.setProperty("javax.net.ssl.trustStorePassword", PASSWORD);
>>> 96:         SSLContext context = new SimpleSSLContext().get();
>> 
>> FYI: We are moving away from using keystore files to generating keystores on the fly as needed. `SimpleSSLContext` is using a keystore file.
>
> `MD5NotAllowedInTLS13CertificateSignature` contains an example.

A lot of (existing) HttpClient tests in `test/jdk/java/net/httpclient` currently use this `SimpleSSLContext` construct to read the `testkeys` keystore that's available in the JDK repo's test directory. Moving to a dynamically created keystore instead of a keystore that's committed in the JDK repo seems reasonable. I think it would be better to do that as a separate task in future, since that would involve updating these existing tests to use this new mechanism too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2055484535

From lbruun at apache.org  Wed Apr 23 08:24:59 2025
From: lbruun at apache.org (Lars Bruun-Hansen)
Date: Wed, 23 Apr 2025 10:24:59 +0200
Subject: JDK-8355338: ZIP and non-compliant entry names
Message-ID: 

I would like to propose a strengthening of the security posture
of the ZIP file implementation.

The java.util.zip implementation is, according to the package docs,
based on the Info-ZIP specification [1] which itself states to be based
on PKWARE's appnote.txt [2]. The latter is probably considered the
"official" specification of the ZIP file format by most. [3]

Over the years these have drifted apart in a crucial area:
the naming of files within the ZIP.


Info-ZIP:
????? The name of the file, with optional relative path.
????? The path stored should not contain a drive or
????? device letter, or a leading slash.? All slashes
????? should be forward slashes '/' as opposed to
????? backwards slashes '\' for compatibility with Amiga
????? and Unix file systems etc.


PKWARE:
????? The name of the file, with optional relative path.
????? The path stored MUST NOT contain a drive or
????? device letter, or a leading slash.? All slashes
????? MUST be forward slashes '/' as opposed to
????? backwards slashes '\' for compatibility with Amiga
????? and UNIX file systems etc.


The difference is the use of "MUST" vs "SHOULD".
I have verified that the PKWARE 'appnote' indeed in the past used
the text as in the Info-ZIP specification. When it exactly changed
I don't know.

The JDK implementation allows backslashes and even allows
a starting slash. In fact, I don't think it has any restrictions at all.
Interestingly, if you create a ZIP using the JDK with entry
names with backslashes in them and then use the Info-ZIP 'unzip'
utility to list or unzip, it will produce a warning but it will accept
the file and be able to explode it. So yes, even Info-ZIP
believes this to be a violation of sorts, at least important
enough to flag it.

I've gone through the javadocs and I cannot find anywhere
mentioned that the implementation is "forgiving" to the extent
it is. I understand the (historical?) need to be able READ zip files
which are not fully compliant. However, in retrospect it would have
been nice if the JDK was a lot less forgiving when CREATING zip files.
But alas, too late to change now. It just seems like a massive
footgun to provide the users of the JDK with.

There is also a security angle: Spoofing file names in ZIP files
is a common technique. Some implementations takes cautionary
steps on this. For example, the Windows Explorer's ZIP reader
simply will not show entries which start with ".." or ".".
Well done, I would say. It is of course unfair to compare a library
(the JDK) to an end-user tool like Windows Explorer as the
objectives are different, however can we fault a user of the JDK
if user would expect the entry names returned from ZipFile class
(i.e. when READING) to be compliant ZIP file names?

Bottom line: My point is that the subtle point that the JDK's
implementation is based off a very old spec from Info-ZIP is likely
to be lost on most users. Now that the "official" spec (PKWARE's) has
become blatantly clear on file naming (except I wish they would have
mentioned that starting the file name with "./" or "../" is illegal too),
I believe the JDK's javadocs should at least have something to say on
the topic of ZIP entry naming and the architectural choices made
in the implementation (accept anything).

So that is my suggestion: a "strengthening" of the Javadoc. I'll be happy
to propose the text. A more thorough approach would be to create new
name entry validating methods and possibly deprecate the existing ones.
Just thought I would propose the easiest solution first: javadoc.

Thoughts?

/Lars


[1]: http://www.info-zip.org/doc/appnote-19970311-iz.zip
[2]: https://pkwaredownloads.blob.core.windows.net/pem/APPNOTE.txt
[3]: The only known attempt - that I know of - from a standardization body
at formalizing the ZIP spec is ISO/IEC.21320-1 This spec is based off
PKWARE's
Zip File Format Specification version 6.3.3.
[3]:
https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/zip/ZipEntry.html#%3Cinit%3E(java.lang.String)


From swen at openjdk.org  Wed Apr 23 08:42:50 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 23 Apr 2025 08:42:50 GMT
Subject: RFR: 8355301: Simplify Throwable::printStackTrace by replacing
 inner class with static method [v4]
In-Reply-To: 
References: 
 <2FArm3JRh9gez7hXK0J3YS8U5tgVTCGxdd0y1qq1cLw=.9593786d-27dd-4bd7-819d-1cd4c125d0bd@github.com>
 
Message-ID: 

On Wed, 23 Apr 2025 06:44:32 GMT, Alan Bateman  wrote:

> Ugh, hopefully this will be replaced in the next iteration.

What should we replace it with? Do you have any suggestions?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24795#discussion_r2055549921

From pminborg at openjdk.org  Wed Apr 23 08:49:12 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 23 Apr 2025 08:49:12 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v73]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 07:41:36 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove section on fun/coll sync

Here is a PR update applicable for https://github.com/openjdk/jdk/pull/23972/commits/1a25b8639b15228287da59fa0856eec1141d5021:

Tests in tier1, tier2, and tier3 pass in a multi-machine CI pipeline.

Here is a link to the generated JavaDocs:  https://cr.openjdk.org/~pminborg/stable-values2/api/java.base/java/lang/StableValue.html

Here are the current benchmark outputs (for an M1 on macOS Sequoia 15.4):


Benchmark                                              Mode  Cnt    Score   Error  Units
StableFunctionBenchmark.function                       avgt   10    4.612 ? 0.882  ns/op
StableFunctionBenchmark.map                            avgt   10    4.738 ? 0.920  ns/op
StableFunctionBenchmark.staticIntFunction              avgt   10    1.653 ? 0.037  ns/op
StableFunctionBenchmark.staticSMap                     avgt   10    2.771 ? 1.747  ns/op
StableFunctionSingleBenchmark.function                 avgt   10    4.268 ? 0.085  ns/op
StableFunctionSingleBenchmark.map                      avgt   10    4.241 ? 0.095  ns/op
StableFunctionSingleBenchmark.staticIntFunction        avgt   10    0.703 ? 0.009  ns/op
StableFunctionSingleBenchmark.staticSMap               avgt   10    0.727 ? 0.055  ns/op
StableIntFunctionBenchmark.intFunction                 avgt   10    1.543 ? 0.038  ns/op
StableIntFunctionBenchmark.list                        avgt   10    1.532 ? 0.061  ns/op
StableIntFunctionBenchmark.staticIntFunction           avgt   10    3.602 ? 0.079  ns/op
StableIntFunctionBenchmark.staticList                  avgt   10    2.279 ? 1.932  ns/op
StableIntFunctionSingleBenchmark.intFunction           avgt   10    2.434 ? 0.044  ns/op
StableIntFunctionSingleBenchmark.list                  avgt   10    2.547 ? 0.125  ns/op
StableIntFunctionSingleBenchmark.staticIntFunction     avgt   10    0.694 ? 0.026  ns/op
StableIntFunctionSingleBenchmark.staticList            avgt   10    0.691 ? 0.018  ns/op
StableMethodHandleBenchmark.atomic                     avgt   10    3.673 ? 0.069  ns/op
StableMethodHandleBenchmark.dcl                        avgt   10    3.645 ? 0.390  ns/op
StableMethodHandleBenchmark.finalMh                    avgt   10    0.712 ? 0.123  ns/op
StableMethodHandleBenchmark.map                        avgt   10    7.431 ? 0.314  ns/op
StableMethodHandleBenchmark.nonFinalMh                 avgt   10    3.170 ? 0.094  ns/op
StableMethodHandleBenchmark.stableMap                  avgt   10    0.695 ? 0.026  ns/op
StableMethodHandleBenchmark.stableMh                   avgt   10    0.698 ? 0.032  ns/op
StableSupplierBenchmark.stable                         avgt   10    1.390 ? 0.055  ns/op
StableSupplierBenchmark.staticStable                   avgt   10    0.373 ? 0.049  ns/op
StableSupplierBenchmark.staticSupplier                 avgt   10    0.352 ? 0.010  ns/op
StableSupplierBenchmark.supplier                       avgt   10    1.610 ? 0.125  ns/op
StableValueBenchmark.atomic                            avgt   10    1.424 ? 0.055  ns/op
StableValueBenchmark.dcl                               avgt   10    1.412 ? 0.044  ns/op
StableValueBenchmark.refSupplier                       avgt   10    0.458 ? 0.021  ns/op
StableValueBenchmark.stable                            avgt   10    1.400 ? 0.066  ns/op
StableValueBenchmark.stableNull                        avgt   10    1.185 ? 0.068  ns/op
StableValueBenchmark.staticAtomic                      avgt   10    1.190 ? 0.046  ns/op
StableValueBenchmark.staticDcl                         avgt   10    0.342 ? 0.014  ns/op
StableValueBenchmark.staticHolder                      avgt   10    1.479 ? 0.181  ns/op
StableValueBenchmark.staticRecordHolder                avgt   10    0.339 ? 0.013  ns/op
StableValueBenchmark.staticStable                      avgt   10    0.336 ? 0.018  ns/op
VarHandleHolderBenchmark.confinedStableFunctionLoop    avgt    5  226.868 ? 2.850  ns/op
VarHandleHolderBenchmark.confinedStableMapElementLoop  avgt    5  147.140 ? 2.885  ns/op
VarHandleHolderBenchmark.confinedStableMapLoop         avgt    5  226.109 ? 5.524  ns/op
VarHandleHolderBenchmark.confinedStableValueLoop       avgt    5  146.908 ? 1.027  ns/op
VarHandleHolderBenchmark.confinedUnmodifiableMapLoop   avgt    5  147.872 ? 6.520  ns/op
VarHandleHolderBenchmark.confinedVarHandleLoop         avgt    5  139.456 ? 3.091  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2823529097

From mli at openjdk.org  Wed Apr 23 08:50:53 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 23 Apr 2025 08:50:53 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v12]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 01:02:19 GMT, Vladimir Ivanov  wrote:

>> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
>> 
>> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
>> 
>> The patch consists of the following parts:
>>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
>> 
>> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
>> 
>> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
>> 
>> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
>> 
>> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
>> 
>> Thanks!
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid thread state transition in VectorSupport_GetCPUFeatures

Found another possible issue on riscv.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 288:

> 286:                   IntFunction> implSupplier,
> 287:                   V v) {
> 288:         var entry = lookup(op, opc, vspecies, implSupplier);

Seems there is another issue for riscv here.
If the rvv extension is not supported on the running machine, it will still generate the code using rvv, this should lead to a crash at runtime?

-------------

PR Review: https://git.openjdk.org/jdk/pull/24462#pullrequestreview-2786445269
PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2055551021

From mli at openjdk.org  Wed Apr 23 08:50:54 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 23 Apr 2025 08:50:54 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v12]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 23 Apr 2025 08:40:44 GMT, Hamlin Li  wrote:

>> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid thread state transition in VectorSupport_GetCPUFeatures
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 288:
> 
>> 286:                   IntFunction> implSupplier,
>> 287:                   V v) {
>> 288:         var entry = lookup(op, opc, vspecies, implSupplier);
> 
> Seems there is another issue for riscv here.
> If the rvv extension is not supported on the running machine, it will still generate the code using rvv, this should lead to a crash at runtime?

In previous code, we use `UseRVV` to detect if rvv extension is supported.

On the other hand, user can choose to disable UseRVV if they want even if rvv extension is supported on the running machine. In this sense, there could be similar issue on other platforms?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2055556734

From mli at openjdk.org  Wed Apr 23 08:56:44 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 23 Apr 2025 08:56:44 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v10]
In-Reply-To: <4c9BdDJr1BWA92Uv7HHIa6_ons9yzW0U6q0uOzKLxPY=.102b7ec5-c4bb-4117-a092-0815d01aa74d@github.com>
References: 
 
 
 
 <4c9BdDJr1BWA92Uv7HHIa6_ons9yzW0U6q0uOzKLxPY=.102b7ec5-c4bb-4117-a092-0815d01aa74d@github.com>
Message-ID: <4LfzOzPmZZ42Aoub8uPvjvAvUjD29tr54PyNQMGSEEM=.fd73d966-b7cc-4695-a79f-fd3c62467ed0@github.com>

On Wed, 23 Apr 2025 00:23:46 GMT, Vladimir Ivanov  wrote:

>> A simple fix could be:
>> 
>> diff --git a/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp b/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp
>> index 484a2a645aa..a785dc65c9e 100644
>> --- a/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp
>> +++ b/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp
>> @@ -196,25 +196,12 @@ void VM_Version::setup_cpu_available_features() {
>>  
>>    _cpu_info_string = os::strdup(buf);
>>  
>> -  _features_string = extract_features_string(_cpu_info_string,
>> -                                             strnlen(_cpu_info_string, sizeof(buf)),
>> -                                             features_offset);
>> +  _features_string = _cpu_info_string;
>>  }
>
> Alternatively, it's fine for now to completely drop `extract_features_string` call on linux-riscv  (as on some other platforms) and fix it separately. Then `VectorSupport.getCPUFeatures()` returns empty string. `VectorMathLibrary` doesn't rely on `CPUFeatures` on RISC-V.
> 
> Let me know how you prefer to handle it.

I think we still need this or similar thing on riscv. Please check my new comments below about rvv extension on riscv.
On the other hand, it's also good to have it on riscv for consistency, and there is a log output of "cpu features" in VectorMathLibrary.java

>> Mayber in `CPUFeatures`, could use the similar code as `CPUInfo` to split the cpu string into cpu features?
>
> The intention is to align `_features_string` with `_features` which enumerates well-known CPU capabilities JVM manages. As of now, `_features_string` contains more information, so I introduced `_cpu_info_string` to keep it.
> 
> Speaking of `test/lib/jdk/test/whitebox/cpuinfo/CPUInfo.java`, the approach chosen there may be fine for a test library, but we need a more stable API between JVM and JDK.

I'm fine with this.
But it might be better to change the spliting regex of  `_features_string` in CPUFeatures.java to support riscv cpu features format.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2055572192
PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2055576765

From alanb at openjdk.org  Wed Apr 23 09:07:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Apr 2025 09:07:50 GMT
Subject: RFR: 8355301: Simplify Throwable::printStackTrace by replacing
 inner class with static method [v4]
In-Reply-To: 
References: 
 <2FArm3JRh9gez7hXK0J3YS8U5tgVTCGxdd0y1qq1cLw=.9593786d-27dd-4bd7-819d-1cd4c125d0bd@github.com>
 
 
Message-ID: 

On Wed, 23 Apr 2025 08:40:04 GMT, Shaojin Wen  wrote:

> What should we replace it with? Do you have any suggestions?

The wrapper classes were needed when there were was a mix of synchronized and j.u.concurrent locks in use. With JEP 491 integrated it meant that the java.io classes could be changed back to use synchronized.  Yes, we could do some cleanup in Throwable too. Changing PrintStreamOrWriter to be an interface should be fine but the rest of these changes in this PR doesn't seem necessary. As others have already asked, I think it would be useful to understand what issue you are running into and why you want to change this code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24795#discussion_r2055596020

From alan.bateman at oracle.com  Wed Apr 23 09:47:34 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Wed, 23 Apr 2025 10:47:34 +0100
Subject: JDK-8355338: ZIP and non-compliant entry names
In-Reply-To: 
References: 
Message-ID: 

On 23/04/2025 09:24, Lars Bruun-Hansen wrote:
> :
>
> There is also a security angle: Spoofing file names in ZIP files
> is a common technique. Some implementations takes cautionary
> steps on this. For example, the Windows Explorer's ZIP reader
> simply will not show entries which start with ".." or ".".
> Well done, I would say. It is of course unfair to compare a library
> (the JDK) to an end-user tool like Windows Explorer as the
> objectives are different, however can we fault a user of the JDK
> if user would expect the entry names returned from ZipFile class
> (i.e. when READING) to be compliant ZIP file names?
>
> Bottom line: My point is that the subtle point that the JDK's
> implementation is based off a very old spec from Info-ZIP is likely
> to be lost on most users. Now that the "official" spec (PKWARE's) has
> become blatantly clear on file naming (except I wish they would have
> mentioned that starting the file name with "./" or "../" is illegal too),
> I believe the JDK's javadocs should at least have something to say on
> the topic of ZIP entry naming and the architectural choices made
> in the implementation (accept anything).
>
> So that is my suggestion: a "strengthening" of the Javadoc. I'll be happy
> to propose the text. A more thorough approach would be to create new
> name entry validating methods and possibly deprecate the existing ones.
> Just thought I would propose the easiest solution first: javadoc.
>

JDK-8355338 was only created this week. As noted, the ZIP spec changed 
from "should not" to "MUST not", a change that was not noticed until 
this bug report.

I think too early to give an opinion on whether to change the spec 
and/or implementation. Preliminary data from a scan of ~1 million 
ZIP/JAR files suggests there aren't too many cases of this but more 
analysis will be required to inform and help narrow down options. Note 
that Oracle employees (and probably many others here) cannot engage in 
any discussion about security issues so discussion here will be more 
focused on the compatibility impact and options.

Most of the ZIP/JAR creation will likely come from tools in the eco 
system, e.g.Maven plugins. I think it would be useful to gather some 
data to see if there are usages of these tools/plugins that would cause 
them to attempt to create ZIP/JAR files with these bad entry names. Is 
this something you have cycles to help gather?

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From asotona at openjdk.org  Wed Apr 23 09:49:51 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 23 Apr 2025 09:49:51 GMT
Subject: RFR: 8354899: Reduce overhead associated with type switches [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Apr 2025 17:20:15 GMT, Chen Liang  wrote:

>> The downcallHandle method in Linker has a complex implementation, and type switches is triggered in multiple places in that handle.
>> 
>> After bytestacks analysis of a simple program that links the native implementation of Class::forName0, it turns out that:
>> 1. there are a few missed usages of type switch in ClassFile API
>> 2. type switch can speed up generation by using explicit stack maps, as stack map gen is over 50% of the generation instructions because the switch is branch-heavy, but the frames are actually simple.
>> 
>> These two combined are not that significant in the overall overhead of downcallHandle, but would be helpful for other workloads.
>
> 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:
> 
>  - Rollback classfile boot speed changes
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/switch-gen-speed
>  - Fix adding potentially unbound labels
>  - 8354899: Reduce overhead associated with type switches

I like that the performance of the Class-File API can be improved in critical use cases like this, even though we don't 100% eat our own dog food.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24705#pullrequestreview-2786692967

From asotona at openjdk.org  Wed Apr 23 09:55:56 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 23 Apr 2025 09:55:56 GMT
Subject: RFR: 8355335: Avoid pattern matching switches in core ClassFile
 API
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Apr 2025 23:28:38 GMT, Chen Liang  wrote:

> A few pattern matching switches exist in the core parts of ClassFile API responsible for transformations and parsing. They are likely to be used in early bootstrap, and pattern matching switches require bootstrap methods, which depend on core ClassFile API.
> 
> For example, currently BlockCodeBuilderImpl prevents BlockCodeBuilder from being used in early bootstrap; luckily we are currently all using manual labels, and as a result this does not surface in lambdas.

Yes, Class-File API use in JDK bootstrap should be safe.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24807#pullrequestreview-2786709255

From aefimov at openjdk.org  Wed Apr 23 10:06:54 2025
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 23 Apr 2025 10:06:54 GMT
Subject: RFR: 8355278: Improve debuggability of
 com/sun/jndi/ldap/LdapPoolTimeoutTest.java test [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Apr 2025 11:08:15 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this test only change which proposes to improve the debuggability of `com/sun/jndi/ldap/LdapPoolTimeoutTest.java`?
>> 
>> This test has been failing intermittently in our CI for several years. Detailed are noted in https://bugs.openjdk.org/browse/JDK-8287062. Most of these failures are because the exception message, in an exception that was raised, contains an unexpected value (apparently `null`). The test doesn't propagate the unexpected exception, thus it's not clear why the exception message is different than what the test expects. The commit in this PR propagates the original exception if the message is unexpected. This should help identify the underlying cause of the test failure, if/when it fails the next time.
>> 
>> I have run this test with these changes and the test continues to pass.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Mikhail's review - print the task number that failed
>  - remove unused imports from the test

The latest version of changes looks good to me. With additional debug information there might be more insigths on the test failure reasons - thanks for adding that.

-------------

Marked as reviewed by aefimov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24793#pullrequestreview-2786741659

From myankelevich at openjdk.org  Wed Apr 23 10:14:42 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 23 Apr 2025 10:14:42 GMT
Subject: RFR: 8355278: Improve debuggability of
 com/sun/jndi/ldap/LdapPoolTimeoutTest.java test [v2]
In-Reply-To: 
References: 
 
Message-ID: <9BsOWXivoleZHX1OIj7jJrIztqNX0IY8yp4Gv8c70-4=.79aaab50-9c93-4403-b05c-de98caa5f06e@github.com>

On Tue, 22 Apr 2025 11:08:15 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this test only change which proposes to improve the debuggability of `com/sun/jndi/ldap/LdapPoolTimeoutTest.java`?
>> 
>> This test has been failing intermittently in our CI for several years. Detailed are noted in https://bugs.openjdk.org/browse/JDK-8287062. Most of these failures are because the exception message, in an exception that was raised, contains an unexpected value (apparently `null`). The test doesn't propagate the unexpected exception, thus it's not clear why the exception message is different than what the test expects. The commit in this PR propagates the original exception if the message is unexpected. This should help identify the underlying cause of the test failure, if/when it fails the next time.
>> 
>> I have run this test with these changes and the test continues to pass.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Mikhail's review - print the task number that failed
>  - remove unused imports from the test

Looks good, thank you for your changes

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24793#issuecomment-2823791738

From vklang at openjdk.org  Wed Apr 23 10:21:00 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 23 Apr 2025 10:21:00 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields in
 java.util.concurrent
Message-ID: 

This Pull Request replaces the uses of Field + setAccessible to modify final fields in java.util.concurrent with Unsafe.

-------------

Commit messages:
 - Update ConcurrentSkipListSet, CopyOnWriteArrayList, and AtomicReferenceArray to use Unsafe rather than Field.setAccessible

Changes: https://git.openjdk.org/jdk/pull/24821/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24821&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355369
  Stats: 29 lines in 3 files changed: 4 ins; 6 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/24821.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24821/head:pull/24821

PR: https://git.openjdk.org/jdk/pull/24821

From lbruun at apache.org  Wed Apr 23 10:29:52 2025
From: lbruun at apache.org (Lars Bruun-Hansen)
Date: Wed, 23 Apr 2025 12:29:52 +0200
Subject: JDK-8355338: ZIP and non-compliant entry names
In-Reply-To: 
References: 
 
Message-ID: 

Agreed, too early.?

No need to make it more complex:


Suggestion:

- First phase: put some notes in Javadoc about this. I'll be happy to
suggest / draft a PR. Adding to javadoc should be uncontroversial and
immediately implementable. Right?

- Second phase:? More thorough analysis: How can the JDK possibly be
amended to be more "compliant" in this area. Not sure an analysis of the
ZIPs in the wild is relevant. In any case, this step is likely to be a
lot more involved and spur discussions: Would breaking changes be
acceptable or better to implement new methods / classes parallel to old
ones?? Etc.?


Further, my suggestion is to create two tickets from JDK-8355338, each
representing the two phases above. This way, if we get bogged down by
discussions on #2 then at least we can say we did #1.? :-)

But yes, I'll be happy to invest time in #2 as well.


/Lars

?

On 23/04/2025 11.47, Alan Bateman wrote:
> On 23/04/2025 09:24, Lars Bruun-Hansen wrote:
>> :
>>
>> There is also a security angle: Spoofing file names in ZIP files
>> is a common technique. Some implementations takes cautionary
>> steps on this. For example, the Windows Explorer's ZIP reader
>> simply will not show entries which start with ".." or ".".
>> Well done, I would say. It is of course unfair to compare a library
>> (the JDK) to an end-user tool like Windows Explorer as the
>> objectives are different, however can we fault a user of the JDK
>> if user would expect the entry names returned from ZipFile class
>> (i.e. when READING) to be compliant ZIP file names?
>>
>> Bottom line: My point is that the subtle point that the JDK's
>> implementation is based off a very old spec from Info-ZIP is likely
>> to be lost on most users. Now that the "official" spec (PKWARE's) has
>> become blatantly clear on file naming (except I wish they would have
>> mentioned that starting the file name with "./" or "../" is illegal too),
>> I believe the JDK's javadocs should at least have something to say on
>> the topic of ZIP entry naming and the architectural choices made
>> in the implementation (accept anything).
>>
>> So that is my suggestion: a "strengthening" of the Javadoc. I'll be happy
>> to propose the text. A more thorough approach would be to create new
>> name entry validating methods and possibly deprecate the existing ones.
>> Just thought I would propose the easiest solution first: javadoc.
>>
>
> JDK-8355338 was only created this week. As noted, the ZIP spec changed
> from "should not" to "MUST not", a change that was not noticed until
> this bug report.
>
> I think too early to give an opinion on whether to change the spec
> and/or implementation. Preliminary data from a scan of ~1 million
> ZIP/JAR files suggests there aren't too many cases of this but more
> analysis will be required to inform and help narrow down options. Note
> that Oracle employees (and probably many others here) cannot engage in
> any discussion about security issues so discussion here will be more
> focused on the compatibility impact and options.
>
> Most of the ZIP/JAR creation will likely come from tools in the eco
> system, e.g.Maven plugins. I think it would be useful to gather some
> data to see if there are usages of these tools/plugins that would
> cause them to attempt to create ZIP/JAR files with these bad entry
> names. Is this something you have cycles to help gather?
>
> -Alan
>

From pminborg at openjdk.org  Wed Apr 23 10:38:22 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 23 Apr 2025 10:38:22 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v74]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 365 commits:

 - Replace 'content' with 'contents' and doc updates
 - Merge branch 'master' into implement-jep502
 - Remove section on fun/coll sync
 - Reformat docs
 - Fix failing test (exception message)
 - Rework relayed to rethrown
 - Fix copyright related issues
 - Fix rawtype problem
 - Fix build problem
 - Resolve merge problem
 - ... and 355 more: https://git.openjdk.org/jdk/compare/27faf454...ac6accd8

-------------

Changes: https://git.openjdk.org/jdk/pull/23972/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=73
  Stats: 4793 lines in 31 files changed: 4769 ins; 0 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From pminborg at openjdk.org  Wed Apr 23 10:46:40 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 23 Apr 2025 10:46:40 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent
In-Reply-To: 
References: 
Message-ID: 

On Wed, 23 Apr 2025 10:10:54 GMT, Viktor Klang  wrote:

> This Pull Request replaces the uses of Field + setAccessible to modify final fields in java.util.concurrent with Unsafe.

src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListSet.java line 534:

> 532:         U.putReference(
> 533:             this,
> 534:             U.objectFieldOffset(ConcurrentSkipListSet.class, "m"),

Would it make sense to compute the offset once and for all and put it in a `static final long` field?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24821#discussion_r2055774428

From michaelm at openjdk.org  Wed Apr 23 10:51:46 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 23 Apr 2025 10:51:46 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <1BMZYXMCLuNxUcGFHy9U6TBYd1pChwilCjVOqXwHQT0=.8f352f4f-afec-40fb-90a5-5d1750b5fc45@github.com>
References: 
 <1BMZYXMCLuNxUcGFHy9U6TBYd1pChwilCjVOqXwHQT0=.8f352f4f-afec-40fb-90a5-5d1750b5fc45@github.com>
Message-ID: 

On Fri, 18 Apr 2025 18:47:52 GMT, Chen Liang  wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement 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.
>
> src/java.net.http/share/classes/java/net/http/HttpResponse.java line 838:
> 
>> 836:         /**
>> 837:          * Represents a HTTP/3 PushID. PushIds can be shared across
>> 838:          * multiple client initiated requests on the same HTTP/3 connection.
> 
> Is this a marker interface for various kinds of push ids? Otherwise just the record is sufficient.

We had to change the API going from HTTP/2 push promise to HTTP/3. So, we want to avoid having to do that again (except where necessary) in any future update to the definition of a Push ID. I think Push Promise is a fairly esoteric aspect of HTTP anyway and won't concern the majority of developers.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2055781501

From tschatzl at openjdk.org  Wed Apr 23 11:46:16 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 23 Apr 2025 11:46:16 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v35]
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 51 commits:

 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review (part 2 - yield duration changes)
 - * ayang review (part 1)
 - * indentation fix
 - * remove support for 32 bit x86 in the barrier generation code, following latest changes from @shade
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * fixes after merge related to 32 bit x86 removal
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review: revising young gen length
   * robcasloz review: various minor refactorings
 - Do not unnecessarily pass around tmp2 in x86
 - ... and 41 more: https://git.openjdk.org/jdk/compare/e76f2030...e4bf1ac0

-------------

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=34
  Stats: 7101 lines in 110 files changed: 2581 ins; 3596 del; 924 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 pminborg at openjdk.org  Wed Apr 23 11:58:20 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 23 Apr 2025 11:58:20 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v75]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rephrase happens-before clause

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/ac6accd8..596b5d00

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=74
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=73-74

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From jbhateja at openjdk.org  Wed Apr 23 11:59:57 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 23 Apr 2025 11:59:57 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v2]
In-Reply-To: 
References: 
 
Message-ID: <-ICBFkGuSGK0-ZPneJvBE-GdrN4B8RJnAlA1_iQ707M=.24b1c5bc-1cbd-49f4-abbc-a0eddc86469d@github.com>

On Fri, 18 Apr 2025 01:36:10 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 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 'master' into JDK-8354242
>  - 8354242: VectorAPI: combine vector not operation with compare
>    
>    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...

src/hotspot/share/opto/vectornode.cpp line 2243:

> 2241:     in1 = in1->in(1);
> 2242:   }
> 2243:   if (in1->Opcode() != Op_VectorMaskCmp || in1->outcnt() > 1 ||

Checks on outcnt on line 2243 and 2238 can be removed. Idealization looks for a specific graph palette and replaces it with a new node whose inputs are the same as the inputs of the palette. GVN will do the retention job if any intermediate node has users beyond the pattern being replaced.

test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java line 38:

> 36:  * @summary test combining vector not operation with compare
> 37:  * @modules jdk.incubator.vector
> 38:  * @requires ((os.arch!="x86" & os.arch!="i386" & os.arch!="amd64" & os.arch!="x86_64") | vm.cpu.features ~= ".*avx.*")

You can remove this platform limitation and forward the constraints to @IR rules using applyIfCPUFeatureOr

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2055741909
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2055787414

From pminborg at openjdk.org  Wed Apr 23 12:12:26 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 23 Apr 2025 12:12:26 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v76]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Replace 'contents' with 'result' in the docs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/596b5d00..538daf4f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=75
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=74-75

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From vklang at openjdk.org  Wed Apr 23 12:12:27 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 23 Apr 2025 12:12:27 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v74]
In-Reply-To: 
References: 
 
Message-ID: <5OYWkeBYYLjeoa7tGtjaYF2nTtmtQbuu6kCIDOlHIPM=.5fbc4081-0b01-4047-b168-51a0c3a8086e@github.com>

On Wed, 23 Apr 2025 10:38:22 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 365 commits:
> 
>  - Replace 'content' with 'contents' and doc updates
>  - Merge branch 'master' into implement-jep502
>  - Remove section on fun/coll sync
>  - Reformat docs
>  - Fix failing test (exception message)
>  - Rework relayed to rethrown
>  - Fix copyright related issues
>  - Fix rawtype problem
>  - Fix build problem
>  - Resolve merge problem
>  - ... and 355 more: https://git.openjdk.org/jdk/compare/27faf454...ac6accd8

src/java.base/share/classes/java/lang/StableValue.java line 119:

> 117:  * The {@code getLogger()} method calls {@code logger.orElseSet()} on the stable value to
> 118:  * retrieve its contents. If the stable value is unset, then {@code orElseSet()}
> 119:  * evaluates the given supplier, and sets the contents to the result; the contents is then

@minborg Technically, isn't the *result* returned to the client (after setting it as the contents).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2055900596

From pminborg at openjdk.org  Wed Apr 23 12:12:27 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 23 Apr 2025 12:12:27 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v74]
In-Reply-To: <5OYWkeBYYLjeoa7tGtjaYF2nTtmtQbuu6kCIDOlHIPM=.5fbc4081-0b01-4047-b168-51a0c3a8086e@github.com>
References: 
 
 <5OYWkeBYYLjeoa7tGtjaYF2nTtmtQbuu6kCIDOlHIPM=.5fbc4081-0b01-4047-b168-51a0c3a8086e@github.com>
Message-ID: <66m87WFeIspf-qA6NoIq83nXsnRvOa55zJq03JBpPxE=.e67d4dd3-fdc2-422a-89a7-56daa56e7ed4@github.com>

On Wed, 23 Apr 2025 12:04:45 GMT, Viktor Klang  wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 365 commits:
>> 
>>  - Replace 'content' with 'contents' and doc updates
>>  - Merge branch 'master' into implement-jep502
>>  - Remove section on fun/coll sync
>>  - Reformat docs
>>  - Fix failing test (exception message)
>>  - Rework relayed to rethrown
>>  - Fix copyright related issues
>>  - Fix rawtype problem
>>  - Fix build problem
>>  - Resolve merge problem
>>  - ... and 355 more: https://git.openjdk.org/jdk/compare/27faf454...ac6accd8
>
> src/java.base/share/classes/java/lang/StableValue.java line 119:
> 
>> 117:  * The {@code getLogger()} method calls {@code logger.orElseSet()} on the stable value to
>> 118:  * retrieve its contents. If the stable value is unset, then {@code orElseSet()}
>> 119:  * evaluates the given supplier, and sets the contents to the result; the contents is then
> 
> @minborg Technically, isn't the *result* returned to the client (after setting it as the contents).

Yeah. I will update that, even though it might be an academic question.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2055905141

From jbhateja at openjdk.org  Wed Apr 23 12:16:48 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 23 Apr 2025 12:16:48 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 18 Apr 2025 01:36:10 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 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 'master' into JDK-8354242
>  - 8354242: VectorAPI: combine vector not operation with compare
>    
>    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...

src/hotspot/share/opto/vectornode.cpp line 2234:

> 2232:   // XorV/XorVMask is commutative, swap VectorMaskCmp/Op_VectorMaskCast to in1.
> 2233:   if (in1->Opcode() != Op_VectorMaskCmp && in1->Opcode() != Op_VectorMaskCast) {
> 2234:     swap(in1, in2);

Swapping inputs like this without refreshing GVN bookkeeping is not safe. I guess you wanted to use Node::swap_edges.

src/hotspot/share/opto/vectornode.cpp line 2265:

> 2263:     vmcmp = new VectorMaskCastNode(phase->transform(vmcmp), vmcast_vt);
> 2264:   }
> 2265:   return vmcmp;

It would be preferable if you could kindly re-factor the code such that we only call VectorNode::Ideal once at return to comply with aesthetics of other idealization routines.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2055908691
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2055911839

From vklang at openjdk.org  Wed Apr 23 12:20:11 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 23 Apr 2025 12:20:11 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v76]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 12:12:26 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace 'contents' with 'result' in the docs

Thanks for all the great work here!

-------------

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23972#pullrequestreview-2787085015

From vklang at openjdk.org  Wed Apr 23 12:23:55 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 23 Apr 2025 12:23:55 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 10:44:05 GMT, Per Minborg  wrote:

>> This Pull Request replaces the uses of Field + setAccessible to modify final fields in java.util.concurrent with Unsafe.
>
> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListSet.java line 534:
> 
>> 532:         U.putReference(
>> 533:             this,
>> 534:             U.objectFieldOffset(ConcurrentSkipListSet.class, "m"),
> 
> Would it make sense to compute the offset once and for all and put it in a `static final long` field?

Yeah, I originally did that, but the following patch is the "smallest change".
Given that the "original code" obtained the Field instance each call, this is still likely a performance improvement.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24821#discussion_r2055927582

From alanb at openjdk.org  Wed Apr 23 12:41:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Apr 2025 12:41:46 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent
In-Reply-To: 
References: 
 
 
Message-ID: <6NDgDTwJ7E3fBSTB-WVtTQLFMkeJwnPo0ex96kpTbag=.1f20daed-f9a0-4e55-b85e-11291c8a7a9d@github.com>

On Wed, 23 Apr 2025 12:21:21 GMT, Viktor Klang  wrote:

>> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListSet.java line 534:
>> 
>>> 532:         U.putReference(
>>> 533:             this,
>>> 534:             U.objectFieldOffset(ConcurrentSkipListSet.class, "m"),
>> 
>> Would it make sense to compute the offset once and for all and put it in a `static final long` field?
>
> Yeah, I originally did that, but the following patch is the "smallest change".
> Given that the "original code" obtained the Field instance each call, this is still likely a performance improvement.

This code has always used getDeclaredField each time so if anyone had run into a performance issue then we should have heard by now. So I think keeping the changes simple and just moving to Unsafe is okay for now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24821#discussion_r2055960041

From alanb at openjdk.org  Wed Apr 23 12:58:43 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Apr 2025 12:58:43 GMT
Subject: RFR: 8350703: Add standard system property stdin.encoding
In-Reply-To: 
References: 
Message-ID: 

On Thu, 17 Apr 2025 18:59:33 GMT, Stuart Marks  wrote:

> * Windows and Unix: set sprops.stdin_encoding if connected to a console
> * Add specs for stdin.encoding
> * Adjust specs to change "undefined" to "unspecified"
> * Rewrite System.in spec to refer to new property and to clarify usage with classes that perform encoding
> * Update property test

Overall I think this looks quite good. Follow-up PR can update APIs beyond System to reference it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24738#issuecomment-2824210223

From alanb at openjdk.org  Wed Apr 23 12:58:44 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Apr 2025 12:58:44 GMT
Subject: RFR: 8350703: Add standard system property stdin.encoding
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 01:33:39 GMT, Naoto Sato  wrote:

>> * Windows and Unix: set sprops.stdin_encoding if connected to a console
>> * Add specs for stdin.encoding
>> * Adjust specs to change "undefined" to "unspecified"
>> * Rewrite System.in spec to refer to new property and to clarify usage with classes that perform encoding
>> * Update property test
>
> src/java.base/share/classes/jdk/internal/util/SystemProps.java line 92:
> 
>> 90: 
>> 91:         // Encoding properties for stdin, stdout, and stderr. For stdout and stderr,
>> 92:         // check "sun.*.encoding" properties before falling back to the
> 
> Could explain about sun* a bit more (just for compatibility) and stdin.encoding is free from it.

I think the comment could be clearer. As I understand it, it's just trying to saying that the legacy sun.stdout.encoding/sun.stderr.encoding properties for stdout/stderr only, no equivalent for stdin.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24738#discussion_r2055991997

From swen at openjdk.org  Wed Apr 23 12:59:42 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 23 Apr 2025 12:59:42 GMT
Subject: RFR: 8355301: Simplify Throwable::printStackTrace by replacing
 inner class with static method [v4]
In-Reply-To: 
References: 
 <2FArm3JRh9gez7hXK0J3YS8U5tgVTCGxdd0y1qq1cLw=.9593786d-27dd-4bd7-819d-1cd4c125d0bd@github.com>
 
 
 
Message-ID: <5WGPSucKl1DAooIH9pyCbPTiDdGrY4IvLiSTP1QeX04=.985e2dfd-a4fc-4e96-b941-df52743bf7ba@github.com>

On Wed, 23 Apr 2025 09:05:07 GMT, Alan Bateman  wrote:

>>> Ugh, hopefully this will be replaced in the next iteration.
>> 
>> What should we replace it with? Do you have any suggestions?
>
>> What should we replace it with? Do you have any suggestions?
> 
> The wrapper classes were needed when there were was a mix of synchronized and j.u.concurrent locks in use. With JEP 491 integrated it meant that the java.io classes could be changed back to use synchronized.  Yes, we could do some cleanup in Throwable too. Changing PrintStreamOrWriter to be an interface should be fine but the rest of these changes in this PR doesn't seem necessary. As others have already asked, I think it would be useful to understand what issue you are running into and why you want to change this code.

Do you mean to suggest reverting to the original version using interface + record?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24795#discussion_r2055997620

From swen at openjdk.org  Wed Apr 23 13:04:56 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 23 Apr 2025 13:04:56 GMT
Subject: Integrated: 8355300: Add final to BitSieve
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Apr 2025 11:10:46 GMT, Shaojin Wen  wrote:

> As the title says, adding final to fields that do not change and BitSieve that will not be inherited will make C2 optimization more friendly.

This pull request has now been integrated.

Changeset: c873837d
Author:    Shaojin Wen 
URL:       https://git.openjdk.org/jdk/commit/c873837da6e373613866f5f5c0017f0fccb97b57
Stats:     5 lines in 1 file changed: 0 ins; 0 del; 5 mod

8355300: Add final to BitSieve

Reviewed-by: liach, pminborg

-------------

PR: https://git.openjdk.org/jdk/pull/24796

From epeter at openjdk.org  Wed Apr 23 13:04:48 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 23 Apr 2025 13:04:48 GMT
Subject: RFR: 8351623: VectorAPI: Refactor subword gather load and add SVE
 implementation
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Apr 2025 01:42:22 GMT, Xiaohong Gong  wrote:

>> ### Summary:
>> [JDK-8318650](http://java-service.client.nvidia.com/?q=8318650) added the hotspot intrinsifying of subword gather load APIs for X86 platforms [1]. This patch aims at implementing the equivalent functionality for AArch64 SVE platform. In addition to the AArch64 backend support, this patch also refactors the API implementation in Java side and the compiler mid-end part to make the operations more efficient and maintainable across different architectures.
>> 
>> ### Background:
>> Vector gather load APIs load values from memory addresses calculated by adding a base pointer to integer indices stored in an int array. SVE provides native vector gather load instructions for byte/short types using an int vector saving indices (see [2][3]).
>> 
>> The number of loaded elements must match the index vector's element count. Since int elements are 4/2 times larger than byte/short elements, and given `MaxVectorSize` constraints, the operation may need to be splitted into multiple parts.
>> 
>> Using a 128-bit byte vector gather load as an example, there are four scenarios with different `MaxVectorSize`:
>> 
>> 1. `MaxVectorSize = 16, byte_vector_size = 16`:
>>    - Can load 4 indices per vector register
>>    - So can finish 4 bytes per gather-load operation
>>    - Requires 4 times of gather-loads and final merge
>>    Example:
>>    ```
>>    byte[] arr = [a, b, c, d, e, f, g, h, i, g, k, l, m, n, o, p, ...]
>>    int[] idx = [3, 2, 4, 1, 5, 7, 5, 2, 0, 6, 7, 1, 15, 10, 11, 9]
>> 
>>    4 gather-load:
>>    idx_v1 = [1 4 2 3]    gather_v1 = [0000 0000 0000 becd]
>>    idx_v2 = [2 5 7 5]    gather_v2 = [0000 0000 0000 cfhf]
>>    idx_v3 = [1 7 6 0]    gather_v3 = [0000 0000 0000 bhga]
>>    idx_v4 = [9 11 10 15] gather_v4 = [0000 0000 0000 jlkp]
>>    merge: v = [jlkp bhga cfhf becd]
>>    ```
>> 
>> 2. `MaxVectorSize = 32, byte_vector_size = MaxVectorSize / 2`:
>>    - Can load 8 indices per vector register
>>    - So can finish 8 bytes per gather-load operation
>>    - Requires 2 times of gather-loads and merge
>>    Example:
>>    ```
>>    byte[] arr = [a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, ...]
>>    int[] index = [3, 2, 4, 1, 5, 7, 5, 2, 0, 6, 7, 1, 15, 10, 11, 9]
>> 
>>    2 gather-load:
>>    idx_v1 = [2 5 7 5 1 4 2 3]
>>    idx_v2 = [9 11 10 15 1 7 6 0]
>>    gather_v1 = [0000 0000 0000 0000 0000 0000 cfhf becd]
>>    gather_v2 = [0000 0000 0000 0000 0000 0000 jlkp bhga]
>>    merge: v = [0000 0000 0000 0000 jlkp bhga cfhf becd]
>>    ```
>> 
>> 3. `MaxVectorSize = 64, byte_v...
>
> Hi @jatin-bhateja , could you please help take a look at this PR especially the X86 part? Thanks a lot!
> Hi @RealFYang , could you please help review the RVV part? Thanks a lot!

@XiaohongGong I had a quick look at your changes and PR description. I wonder if you could split some of the refactoring into a separate PR? That would make it easier to review. Currently, you basically have x64 changes, aarch64 changes, Java library changes, and C2 changes. That's a lot at once. And it would basically require the review from a lot of different people at once.

Splitting would make it easier to review, less work for the reviewer. It would ensure everybody can look at a smaller change set, and that would also increase the quality of the code after review, I think.

What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24679#issuecomment-2824229233

From abarashev at openjdk.org  Wed Apr 23 13:09:48 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 23 Apr 2025 13:09:48 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: 
References: 
 <9rWMdJ_KuW5Auws9DtD_pOWt2Mb4-nGLBDmN0DLFA_0=.c8106398-609d-482d-a5bf-b8b78bb8144d@github.com>
 
 
Message-ID: 

On Wed, 23 Apr 2025 08:03:02 GMT, Jaikiran Pai  wrote:

>> `MD5NotAllowedInTLS13CertificateSignature` contains an example.
>
> A lot of (existing) HttpClient tests in `test/jdk/java/net/httpclient` currently use this `SimpleSSLContext` construct to read the `testkeys` keystore that's available in the JDK repo's test directory. Moving to a dynamically created keystore instead of a keystore that's committed in the JDK repo seems reasonable. I think it would be better to do that as a separate task in future, since that would involve updating these existing tests to use this new mechanism too.

Sounds good, this was just FYI.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2056016233

From rgiulietti at openjdk.org  Wed Apr 23 13:13:48 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 23 Apr 2025 13:13:48 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Apr 2025 21:57:19 GMT, Chen Liang  wrote:

>> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list".
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shorter first sentence

src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 70:

> 68:  * accessed by the current thread: shared fields must be read into local
> 69:  * variables, and shared arrays must be copied to an exclusive copy, to ensure
> 70:  * each shared location (a field or an array component) is accessed exactly once.

Suggestion:

 * each shared location (a field or an array component) is accessed at most once.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24777#discussion_r2056018522

From jpai at openjdk.org  Wed Apr 23 13:29:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 23 Apr 2025 13:29:53 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Apr 2025 18:55:28 GMT, Artur Barashev  wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement 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.
>
> test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 86:
> 
>> 84:     public static void main(String[] args) throws Exception {
>> 85:         // re-enable 3DES
>> 86:         Security.setProperty("jdk.tls.disabledAlgorithms", "");
> 
> Use `SecurityUtils.removeFromDisabledAlgs` and only remove 3DES from this property.

Thank you for pointing to `SecurityUtils`. I updated this test to use that test library and the test continues to work as expected. We will include this change in the next refresh of the PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2056058005

From Hempushpa.Sahu at ibm.com  Wed Apr 23 14:03:05 2025
From: Hempushpa.Sahu at ibm.com (Hempushpa Sahu)
Date: Wed, 23 Apr 2025 14:03:05 +0000
Subject: Namespace Prefix Issue in XML to XSL Transformation
Message-ID: 

Problem Description :
XSLT transformation creating unique namespace prefixes.

Analysis & Observation :
The XSLT transformation is generating a new namespace prefix for every XML element, even when the namespace value matches that of the parent element. This leads to large XML file transformations exceeding the file size and memory limits on our systems.

The behaviour in OpenJDK has remained consistent since JDK 8; however, the namespace prefix issue is not something we find optimum.

During our investigation of the OpenJDK codebase, we identified defect https://bugs.openjdk.org/browse/JDK-8167179, which was intended to resolve the namespace prefix issue in the OpenJDK 8 release. However, our testing confirms that the issue persists across multiple versions, including OpenJDK 8, 11, 17, and 22. Additionally, we found an open bug report https://bugs.openjdk.org/browse/JDK-8168664 in the OpenJDK issue tracker referencing a similar problem. Notably, there has been no recent activity on this bug for several years

Suggested Solution:
Introduced a hashmap, and storing the unique namespace-url from root node and checking if new url namespace-url encountered then we will store it in the hashmap and increment the namespace prefix, else we will not increment the prefix.

Implemented in existing function startXslElement() of src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java

              else {
        // Need to generate a prefix?
        if (namespace != null && namespace.length() > 0) {
            prefix = generatePrefix();
            qname = prefix + ':' + qname;
            handler.startElement(namespace, qname, qname);
            handler.namespaceAfterStartElement(prefix, namespace);
        }

The above code is changed to

              else {
        // Need to generate a prefix?
                             if (namespace != null && namespace.length() > 0) {
                                           //Check if prefix needs to be incremented.
                                           if (!namespaceMap.containsKey(namespace))
                                           {
                                                          namespaceMap.put(namespace, threadLocalPrefixIndex.get().getAndIncrement());
                                                          prefix = "ns"+namespaceMap.get(namespace);
                                                          qname = prefix + ':' + qname;
                                                          handler.startElement(namespace, qname, qname);
                                                         handler.namespaceAfterStartElement(prefix, namespace);
                                           }
                                           else
                                           {
                                                          //Namespace URI already exist in map.
                                                          prefix = "ns"+namespaceMap.get(namespace);
                                                          qname = prefix + ':' + qname;
                                                          handler.startElement(namespace, qname, qname);
                                                         handler.namespaceAfterStartElement(prefix, namespace);

                                           }
                             }

Releases:
OpenJDK 8, 11, 17 & 22 the issue is seen.

Note:
Proceeding with this approach, we will need to update the test files. For instance, we have identified one test case that validates the namespace prefix in the result - test/jaxp/javax/xml/jaxp/unittest/transform/NamespacePrefixTest.java

Next steps:
We want to take the above-mentioned fix to OpenJDK.

Please review and suggest if the above understanding is right and we shall take the fix to OpenJDK.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From liach at openjdk.org  Wed Apr 23 14:08:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Apr 2025 14:08:53 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent
In-Reply-To: 
References: 
Message-ID: 

On Wed, 23 Apr 2025 10:10:54 GMT, Viktor Klang  wrote:

> This Pull Request replaces the uses of Field + setAccessible to modify final fields in java.util.concurrent with Unsafe.

Seems these are used mainly for cloning: is it possible for us to just use `readResolve` to resolve an alternative object?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24821#issuecomment-2824433372

From duke at openjdk.org  Wed Apr 23 14:11:56 2025
From: duke at openjdk.org (duke)
Date: Wed, 23 Apr 2025 14:11:56 GMT
Subject: Withdrawn: 8347408: Create an internal method handle adapter for
 system calls with errno
In-Reply-To: 
References: 
Message-ID: 

On Tue, 25 Feb 2025 08:27:26 GMT, Per Minborg  wrote:

> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
> 
> 
> Here are some benchmarks that ran on a platform thread and virtual threads respectively (M1 Mac):
> 
> 
> Benchmark                                                  Mode  Cnt   Score   Error  Units
> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.330 ? 0.820  ns/op
> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.257 ? 0.117  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  41.415 ? 1.013  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.720 ? 0.463  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.636 ? 0.182  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.234 ? 0.156  ns/op
> CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.918 ? 0.487  ns/op
> CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   4.946 ? 0.089  ns/op
> CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.280 ? 1.128  ns/op
> CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  21.809 ? 0.413  ns/op
> CaptureStateUtilBench.tlAllocationFail                     avgt   30  24.422 ? 0.673  ns/op
> CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   5.182 ? 0.152  ns/op
> 
> 
> Adapted system call:
> 
>         return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool
> ```        
> Explicit allocation:
> 
>         try (var arena = Arena.ofConfined()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
>         }
> ```        
> Thread Local allocation:
> 
>         try (var arena = POOLS.take()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool
>         }
> ```        
> The adapted system call exhibits a ~4x performance improvement over the existing "explicit allocation" scheme for the happy path on platform threads. ...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/23765

From liach at openjdk.org  Wed Apr 23 14:12:29 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Apr 2025 14:12:29 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v5]
In-Reply-To: 
References: 
Message-ID: <4cfCydBqbJcxVuRmEf7W4ehFuz_MMf_zc4k5dxpQoCU=.cc4aaf74-5a6a-4213-857b-6b5f69fb63d1@github.com>

> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list".

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java
  
  Co-authored-by: Raffaello Giulietti 

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24777/files
  - new: https://git.openjdk.org/jdk/pull/24777/files/d7b652e3..24ed1cc1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24777&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24777&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24777.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24777/head:pull/24777

PR: https://git.openjdk.org/jdk/pull/24777

From rgiulietti at openjdk.org  Wed Apr 23 14:16:51 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 23 Apr 2025 14:16:51 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent
In-Reply-To: 
References: 
Message-ID: 

On Wed, 23 Apr 2025 10:10:54 GMT, Viktor Klang  wrote:

> This Pull Request replaces the uses of Field + setAccessible to modify final fields in java.util.concurrent with Unsafe.

I guess the intent is just to have the minimal patch to come away from `setAccessible()`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24821#issuecomment-2824455033

From vklang at openjdk.org  Wed Apr 23 14:16:50 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 23 Apr 2025 14:16:50 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 14:06:27 GMT, Chen Liang  wrote:

>> This Pull Request replaces the uses of Field + setAccessible to modify final fields in java.util.concurrent with Unsafe.
>
> Seems these are used mainly for cloning: is it possible for us to just use `readResolve` to resolve an alternative object?

@liach Not sure I understand, could you elaborate a bit?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24821#issuecomment-2824454986

From alanb at openjdk.org  Wed Apr 23 14:16:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Apr 2025 14:16:51 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 14:11:59 GMT, Raffaello Giulietti  wrote:

> I guess the intent is just to have the minimal patch to come away from `setAccessible()`.

It's to move away from using Field.set to mutate non-static final fields. Viktor offered to get this done before the "prepare for final means final" changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24821#issuecomment-2824462984

From jpai at openjdk.org  Wed Apr 23 14:26:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 23 Apr 2025 14:26:57 GMT
Subject: Integrated: 8355278: Improve debuggability of
 com/sun/jndi/ldap/LdapPoolTimeoutTest.java test
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Apr 2025 09:05:09 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this test only change which proposes to improve the debuggability of `com/sun/jndi/ldap/LdapPoolTimeoutTest.java`?
> 
> This test has been failing intermittently in our CI for several years. Detailed are noted in https://bugs.openjdk.org/browse/JDK-8287062. Most of these failures are because the exception message, in an exception that was raised, contains an unexpected value (apparently `null`). The test doesn't propagate the unexpected exception, thus it's not clear why the exception message is different than what the test expects. The commit in this PR propagates the original exception if the message is unexpected. This should help identify the underlying cause of the test failure, if/when it fails the next time.
> 
> I have run this test with these changes and the test continues to pass.

This pull request has now been integrated.

Changeset: 6befc189
Author:    Jaikiran Pai 
URL:       https://git.openjdk.org/jdk/commit/6befc189741069cc4b188e4822541fb9ab72ee28
Stats:     34 lines in 1 file changed: 14 ins; 9 del; 11 mod

8355278: Improve debuggability of com/sun/jndi/ldap/LdapPoolTimeoutTest.java test

Reviewed-by: aefimov

-------------

PR: https://git.openjdk.org/jdk/pull/24793

From jpai at openjdk.org  Wed Apr 23 14:26:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 23 Apr 2025 14:26:56 GMT
Subject: RFR: 8355278: Improve debuggability of
 com/sun/jndi/ldap/LdapPoolTimeoutTest.java test [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Apr 2025 11:08:15 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this test only change which proposes to improve the debuggability of `com/sun/jndi/ldap/LdapPoolTimeoutTest.java`?
>> 
>> This test has been failing intermittently in our CI for several years. Detailed are noted in https://bugs.openjdk.org/browse/JDK-8287062. Most of these failures are because the exception message, in an exception that was raised, contains an unexpected value (apparently `null`). The test doesn't propagate the unexpected exception, thus it's not clear why the exception message is different than what the test expects. The commit in this PR propagates the original exception if the message is unexpected. This should help identify the underlying cause of the test failure, if/when it fails the next time.
>> 
>> I have run this test with these changes and the test continues to pass.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Mikhail's review - print the task number that failed
>  - remove unused imports from the test

Thank you Aleksei and Mikhail for the reviews. I'll go ahead and integrate this now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24793#issuecomment-2824491218

From liach at openjdk.org  Wed Apr 23 14:56:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Apr 2025 14:56:47 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 14:06:27 GMT, Chen Liang  wrote:

>> This Pull Request replaces the uses of Field + setAccessible to modify final fields in java.util.concurrent with Unsafe.
>
> Seems these are used mainly for cloning: is it possible for us to just use `readResolve` to resolve an alternative object?

> @liach Not sure I understand, could you elaborate a bit?

I mean that we call the setters in `readObject` methods. If we can instead call `readResolve` to provide safely constructed objects from constructors, that may be better, but since we are looking at marshalling guess we will not touch serialization.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24821#issuecomment-2824591150

From jiangli at openjdk.org  Wed Apr 23 14:57:48 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 23 Apr 2025 14:57:48 GMT
Subject: RFR: 8354898: jdk/internal/loader/NativeLibraries/Main.java fails
 on static JDK
In-Reply-To: 
References: 
 <68U_vj5WY81keMaVqgpGwGWjvOEfBhIcR1kpf_noOgk=.49e2b7b2-9a0c-4187-b702-cf3cb5b1255d@github.com>
 
 
Message-ID: 

On Wed, 23 Apr 2025 01:11:24 GMT, Jaikiran Pai  wrote:

>>> Hello Jiangli, can you add a few more details to the linked JBS issue? If I understand this change correctly, then what's being proposed in this PR seems to indicate that the `jdk.internal.loader.RawNativeLibraries` is unable to load `libzip` whose `Path` is determined by a call to the `System.mapLibraryName(...)` standard API. I don't currently have access to a static JDK. Can you include the `Path` that's returned for `System.mapLibraryName("zip")` on a static JDK?
>> 
>> @jaikiran Added details in https://bugs.openjdk.org/browse/JDK-8354898, thanks for the suggestion. I also added command line examples for building `static-jdk` and the current method for running jtreg tests on `static-jdk`.
>
>> I also added command line examples for building static-jdk and the current method for running jtreg tests on static-jdk.
> 
> Thank you, that will help me in future.

@jaikiran Thank's a lot for the careful review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24704#issuecomment-2824589483

From jiangli at openjdk.org  Wed Apr 23 14:57:48 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 23 Apr 2025 14:57:48 GMT
Subject: Integrated: 8354898: jdk/internal/loader/NativeLibraries/Main.java
 fails on static JDK
In-Reply-To: 
References: 
Message-ID: 

On Wed, 16 Apr 2025 23:41:40 GMT, Jiangli Zhou  wrote:

> Please review this simple test change that skips the test case loading using JDK `libzip.so` on static JDK in test/jdk/jdk/internal/loader/NativeLibraries/Main.java. AFAICT, the test case using `NativeLibrariesTest.LIB_NAME` (`libnativeLibrariesTest.so`) can provide coverage on static JDK.
> 
> Thanks

This pull request has now been integrated.

Changeset: 12c3a231
Author:    Jiangli Zhou 
URL:       https://git.openjdk.org/jdk/commit/12c3a231e6c1709660e61995f09ad857858e2e36
Stats:     6 lines in 1 file changed: 4 ins; 0 del; 2 mod

8354898: jdk/internal/loader/NativeLibraries/Main.java fails on static JDK

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/24704

From rgiulietti at openjdk.org  Wed Apr 23 15:09:51 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 23 Apr 2025 15:09:51 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent
In-Reply-To: 
References: 
 
 
Message-ID: <7-bzBkKK0oP9EyqMqfLbKX0FVRVU9B7xBwGvohgxwlk=.5888066c-2a36-4ddb-877b-e121ee0caa26@github.com>

On Wed, 23 Apr 2025 14:11:59 GMT, Viktor Klang  wrote:

>> Seems these are used mainly for cloning: is it possible for us to just use `readResolve` to resolve an alternative object?
>
> @liach Not sure I understand, could you elaborate a bit?

@viktorklang-ora Before approving, what is the status of the copyright notices? There seem to be no years to update...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24821#issuecomment-2824631635

From vklang at openjdk.org  Wed Apr 23 15:22:37 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 23 Apr 2025 15:22:37 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent [v2]
In-Reply-To: 
References: 
Message-ID: 

> This Pull Request replaces the uses of Field + setAccessible to modify final fields in java.util.concurrent with Unsafe.

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Adding a releaseFence() to ConcurrentskipListSet.clone()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24821/files
  - new: https://git.openjdk.org/jdk/pull/24821/files/e6e7ac01..39dba5dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24821&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24821&range=00-01

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24821.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24821/head:pull/24821

PR: https://git.openjdk.org/jdk/pull/24821

From vklang at openjdk.org  Wed Apr 23 15:22:38 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 23 Apr 2025 15:22:38 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 15:18:49 GMT, Viktor Klang  wrote:

>> This Pull Request replaces the uses of Field + setAccessible to modify final fields in java.util.concurrent with Unsafe.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding a releaseFence() to ConcurrentskipListSet.clone()

src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListSet.java line 182:

> 180:             clone.setMap(new ConcurrentSkipListMap(m));
> 181:             // Needed to ensure safe publication of setMap()
> 182:             VarHandle.releaseFence();

@DougLea This might be interesting to you. ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24821#discussion_r2056298674

From jlahoda at openjdk.org  Wed Apr 23 15:23:56 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 23 Apr 2025 15:23:56 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: <27MmSGcf2J0xfAsT-Wzce_XhwBStzrfl_prqSxcjGBM=.4c35df47-379b-42e1-b4dd-501f31464b46@github.com>

On Tue, 22 Apr 2025 10:14:44 GMT, Jan Lahoda  wrote:

>> src/java.base/share/classes/jdk/internal/misc/MethodFinder.java line 89:
>> 
>>> 87:         if (mainMethod == null) {
>>> 88:             //if not public method, try to lookup a non-public one
>>> 89:             mainMethod = JLA.findMethod(cls, false, "main", String[].class);
>> 
>> Is there a reason why the first findMethod can't use publicOnly=false?
>
> My reason was that when `publicOnly=false`, there's more classloading happening (unsurprisingly, as also the non-public methods must be resolved). Which may lead to a change of behavior if the traditional `public static main(String[])` exists.
> 
> IIRC there is a test relying on this behavior, but I don't have the name offhand. Will put it here when I have it.
> 
> For example:
> 
> $ cat Main.java 
> public class Main {
>     public static void main(String... args) {
>         System.err.println("Hello!");
>     }
>     private Missing get() { return null; }
> }
> $ cat Missing.java 
> public class Missing {
> }
> $ jdk-24/bin/javac Main.java Missing.java; rm Missing.class
> $ jdk-24/bin/java -classpath . Main
> Hello!
> $ jdk-without-publicOnly=true/bin/java -classpath . Main
> Error: Unable to initialize main class Main
> Caused by: java.lang.NoClassDefFoundError: Missing

The tests that would be affected by the extra classloading appear to be:

test/jdk/java/lang/System/SecurityManagerWarnings.java
test/jdk/java/lang/System/LoggerFinder/SignedLoggerFinderTest/SignedLoggerFinderTest.java

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2056303456

From duke at openjdk.org  Wed Apr 23 15:27:59 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Wed, 23 Apr 2025 15:27:59 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v12]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
Message-ID: 

On Tue, 22 Apr 2025 17:12:52 GMT, Brian Burkhalter  wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8354724: Add missing toList(), tweak verbiage; update test

test/jdk/java/io/BufferedReader/ReadAll.java line 83:

> 81:                 int toIndex = rnd.nextInt(fromIndex, plen);
> 82:                 String str = PHRASE.substring(fromIndex, toIndex);
> 83:                 byte[] strBytes = str.getBytes();

The test will fail if the default Charset is not UTF-8:
`String.getBytes()` and` FileReader(File)` use the default Charset, `Files.readAllLines(Path)` and `Files.readString(Path)` use UTF-8.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2056258447

From bpb at openjdk.org  Wed Apr 23 15:27:59 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Apr 2025 15:27:59 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v12]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
Message-ID: 

On Tue, 22 Apr 2025 17:12:52 GMT, Brian Burkhalter  wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8354724: Add missing toList(), tweak verbiage; update test

Do we have sufficient consensus here to proceed with a CSR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24728#issuecomment-2824680636

From vklang at openjdk.org  Wed Apr 23 15:37:47 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 23 Apr 2025 15:37:47 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent
In-Reply-To: <7-bzBkKK0oP9EyqMqfLbKX0FVRVU9B7xBwGvohgxwlk=.5888066c-2a36-4ddb-877b-e121ee0caa26@github.com>
References: 
 
 
 <7-bzBkKK0oP9EyqMqfLbKX0FVRVU9B7xBwGvohgxwlk=.5888066c-2a36-4ddb-877b-e121ee0caa26@github.com>
Message-ID: 

On Wed, 23 Apr 2025 15:07:33 GMT, Raffaello Giulietti  wrote:

>> @liach Not sure I understand, could you elaborate a bit?
>
> @viktorklang-ora Before approving, what is the status of the copyright notices? There seem to be no years to update...

@rgiulietti These are the JSR166 files, so I didn't touch the copyright notices.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24821#issuecomment-2824715390

From alanb at openjdk.org  Wed Apr 23 15:42:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Apr 2025 15:42:48 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 14:06:27 GMT, Chen Liang  wrote:

> Seems these are used mainly for cloning: is it possible for us to just use `readResolve` to resolve an alternative object?

Potentially AtomicReferenceArray.readObject could be replaced, the others are clone methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24821#issuecomment-2824721516

From bpb at openjdk.org  Wed Apr 23 15:42:44 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Apr 2025 15:42:44 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v12]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
Message-ID: 

On Wed, 23 Apr 2025 14:58:16 GMT, Johannes D?bler  wrote:

> The test will fail if the default Charset is not UTF-8

When does that happen (cf. [JEP 400)](https://openjdk.org/jeps/400)?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2056340354

From duke at openjdk.org  Wed Apr 23 16:01:54 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Wed, 23 Apr 2025 16:01:54 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v12]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
 
Message-ID: 

On Wed, 23 Apr 2025 15:39:35 GMT, Brian Burkhalter  wrote:

>> test/jdk/java/io/BufferedReader/ReadAll.java line 83:
>> 
>>> 81:                 int toIndex = rnd.nextInt(fromIndex, plen);
>>> 82:                 String str = PHRASE.substring(fromIndex, toIndex);
>>> 83:                 byte[] strBytes = str.getBytes();
>> 
>> The test will fail if the default Charset is not UTF-8:
>> `String.getBytes()` and` FileReader(File)` use the default Charset, `Files.readAllLines(Path)` and `Files.readString(Path)` use UTF-8.
>
>> The test will fail if the default Charset is not UTF-8
> 
> When does that happen (cf. [JEP 400)](https://openjdk.org/jeps/400)?

The default charset is not UTF-8 when you specify JVM param -Dfile.encoding, which of course is unlikely in the environment which executes the test. But imho being explicit about the charset does not hurt.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2056387430

From naoto at openjdk.org  Wed Apr 23 16:10:57 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 23 Apr 2025 16:10:57 GMT
Subject: RFR: 8355215: Add @spec tags to Emoji related methods
In-Reply-To: 
References: 
Message-ID: 

On Mon, 21 Apr 2025 20:11:47 GMT, Naoto Sato  wrote:

> Adding @spec tags to Emoji related methods in the Character class. A CSR has also been drafted.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24779#issuecomment-2824812290

From naoto at openjdk.org  Wed Apr 23 16:10:58 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 23 Apr 2025 16:10:58 GMT
Subject: Integrated: 8355215: Add @spec tags to Emoji related methods
In-Reply-To: 
References: 
Message-ID: 

On Mon, 21 Apr 2025 20:11:47 GMT, Naoto Sato  wrote:

> Adding @spec tags to Emoji related methods in the Character class. A CSR has also been drafted.

This pull request has now been integrated.

Changeset: f097aa90
Author:    Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/f097aa90c91826ba6c3c7380a84b8e98f1d42bbb
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8355215: Add @spec tags to Emoji related methods

Reviewed-by: joehw, iris, jlu

-------------

PR: https://git.openjdk.org/jdk/pull/24779

From duke at openjdk.org  Wed Apr 23 16:12:46 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Wed, 23 Apr 2025 16:12:46 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v12]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
Message-ID: <2dIxH6sPnDSKhEgzLGRFtAk1cJYHGN23_yNgUBVM_xY=.dff716e0-a174-47cf-86df-986465afb01e@github.com>

On Tue, 22 Apr 2025 17:12:52 GMT, Brian Burkhalter  wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8354724: Add missing toList(), tweak verbiage; update test

test/jdk/java/io/BufferedReader/ReadAll.java line 72:

> 70:         int size = rnd.nextInt(2, 16386);
> 71: 
> 72:         try (FileChannel fc = FileChannel.open(path, CREATE, WRITE)) {

Why not just create a `List` of lines and then write it to the file using `Files.write(Path, Iterable, Charset, OpenOption...)`

test/jdk/java/io/BufferedReader/ReadAll.java line 107:

> 105:         List lines;
> 106:         try (FileReader fr = new FileReader(file);
> 107:              BufferedReader br = new BufferedReader(fr)) {

could be simplified to
try (BufferedReader br = new BufferedReader(new FileReader(file))) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2056402107
PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2056407359

From lmesnik at openjdk.org  Wed Apr 23 16:15:56 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 23 Apr 2025 16:15:56 GMT
Subject: Integrated: 8353214: Add testing with --enable-preview
In-Reply-To: <-PL85c8ObM1KN0uVIMTglhh6apK6fWXHFO_XdbE0UWI=.589ff6c6-b65a-48c8-807a-1960d72cac09@github.com>
References: <-PL85c8ObM1KN0uVIMTglhh6apK6fWXHFO_XdbE0UWI=.589ff6c6-b65a-48c8-807a-1960d72cac09@github.com>
Message-ID: 

On Thu, 17 Apr 2025 00:24:50 GMT, Leonid Mesnik  wrote:

> Added problemlists and and requires for execution tests with --enable-preview.
> 
> The --enable-preview features might significantly change VM/JDK behavior and sometimes it is useful to run tests with preview features enabled. Eventually preview features should be made default and it is expected that all tests should still work. 
> 
> The tests that are not compatible with --enable-preview, usually because of compilation mode are marked with corresponding requires tag.

This pull request has now been integrated.

Changeset: 2ec61f0f
Author:    Leonid Mesnik 
URL:       https://git.openjdk.org/jdk/commit/2ec61f0f34d2fa313ae3ed5d6aa0881ec091b347
Stats:     69 lines in 4 files changed: 69 ins; 0 del; 0 mod

8353214: Add testing with --enable-preview

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/24706

From liach at openjdk.org  Wed Apr 23 16:25:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Apr 2025 16:25:43 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 15:22:37 GMT, Viktor Klang  wrote:

>> This Pull Request replaces the uses of Field + setAccessible to modify final fields in java.util.concurrent with Unsafe.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding a releaseFence() to ConcurrentskipListSet.clone()

Thanks. We can investigate how clone cleanups interact with truly final or strict finals in another issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24821#issuecomment-2824852312

From bpb at openjdk.org  Wed Apr 23 16:36:42 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Apr 2025 16:36:42 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v12]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
 
 
Message-ID: 

On Wed, 23 Apr 2025 15:58:41 GMT, Johannes D?bler  wrote:

>>> The test will fail if the default Charset is not UTF-8
>> 
>> When does that happen (cf. [JEP 400)](https://openjdk.org/jeps/400)?
>
> The default charset is not UTF-8 when you specify JVM param -Dfile.encoding, which of course is unlikely in the environment which executes the test. But imho being explicit about the charset does not hurt.

True, it would do more harm, but it would require `othervm`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2056464162

From bpb at openjdk.org  Wed Apr 23 16:52:29 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Apr 2025 16:52:29 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v13]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: 

> Implement the requested methods and add a test thereof.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8354724: Improve test per reviewer comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/0600f939..edb813da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=11-12

  Stats: 32 lines in 1 file changed: 3 ins; 22 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728

PR: https://git.openjdk.org/jdk/pull/24728

From bpb at openjdk.org  Wed Apr 23 16:52:30 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Apr 2025 16:52:30 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v12]
In-Reply-To: <2dIxH6sPnDSKhEgzLGRFtAk1cJYHGN23_yNgUBVM_xY=.dff716e0-a174-47cf-86df-986465afb01e@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 <2dIxH6sPnDSKhEgzLGRFtAk1cJYHGN23_yNgUBVM_xY=.dff716e0-a174-47cf-86df-986465afb01e@github.com>
Message-ID: 

On Wed, 23 Apr 2025 16:06:54 GMT, Johannes D?bler  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8354724: Add missing toList(), tweak verbiage; update test
>
> test/jdk/java/io/BufferedReader/ReadAll.java line 72:
> 
>> 70:         int size = rnd.nextInt(2, 16386);
>> 71: 
>> 72:         try (FileChannel fc = FileChannel.open(path, CREATE, WRITE)) {
> 
> Why not just create a `List` of lines and then write it to the file using `Files.write(Path, Iterable, Charset, OpenOption...)`

Good idea: much more compact. So changed in [edb813d](https://github.com/openjdk/jdk/pull/24728/commits/edb813da0057e78e44543c55000e174456cbe965). Thanks.

> test/jdk/java/io/BufferedReader/ReadAll.java line 107:
> 
>> 105:         List lines;
>> 106:         try (FileReader fr = new FileReader(file);
>> 107:              BufferedReader br = new BufferedReader(fr)) {
> 
> could be simplified to
> try (BufferedReader br = new BufferedReader(new FileReader(file))) {

Indeed that is better. So changed in [edb813d](https://github.com/openjdk/jdk/pull/24728/commits/edb813da0057e78e44543c55000e174456cbe965).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2056497453
PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2056497701

From jlu at openjdk.org  Wed Apr 23 16:55:59 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 23 Apr 2025 16:55:59 GMT
Subject: Integrated: 8354343: Hardening of Currency tests for not yet defined
 future ISO 4217 currency
In-Reply-To: 
References: 
Message-ID: 

On Mon, 21 Apr 2025 21:51:35 GMT, Justin Lu  wrote:

> Please review this PR which improves future currency checking for ISO 4217 currencies.
> 
> Checking for a currency that should not yet exist in the set of available currencies is already done.
> It should also be explicitly checked that such a currency can not be instantiated as well via the String getter.

This pull request has now been integrated.

Changeset: ac41bc31
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/ac41bc31c96951b9fe51c22d16f31bdc1806a881
Stats:     36 lines in 1 file changed: 34 ins; 0 del; 2 mod

8354343: Hardening of Currency tests for not yet defined future ISO 4217 currency

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/24782

From liach at openjdk.org  Wed Apr 23 17:07:16 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Apr 2025 17:07:16 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
In-Reply-To: 
References: 
Message-ID: <27AUOnvHzPgj3-Dd_NkiQTExFutYLBzV94cdJvM_7WE=.dc1ed03e-71f8-4c44-b5f0-a5c83dbd78bc@github.com>

On Wed, 23 Apr 2025 14:05:58 GMT, Per Minborg  wrote:

> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
> 
> Re-allocated segments are not zeroed between allocations.

Looks to be in parity with the original patch.

Can we just cleanly revert commit 77647421c5b13738f6fa145bf30cbb9dd741e164?
This new version defines redundant sealed interface + record - feels unnecessary to me.
Meanwhile, the BufferStackBench is valueable, but its addition should be kept in a separate commit to make reviewing easier.

`trust_final_non_static_fields` in `ciField` already trusts `jdk.internal.foreign`, so I don't think the record performance argument stands here. But making Frame and BufferStack classes final is a good move.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24829#pullrequestreview-2788100611
PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2824546993
PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2824731824

From pminborg at openjdk.org  Wed Apr 23 17:07:16 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 23 Apr 2025 17:07:16 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
Message-ID: 

This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.

Re-allocated segments are not zeroed between allocations.

-------------

Commit messages:
 - Remove interface level
 - Add benchmark class with virtual executor
 - Add rudimentary documentation
 - Convert class to record and add @ForceInline
 - Refactor and add benchmark
 - Merge branch 'master' into internal-allocator
 - Change set from previous PR

Changes: https://git.openjdk.org/jdk/pull/24829/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24829&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349146
  Stats: 589 lines in 8 files changed: 568 ins; 15 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24829.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24829/head:pull/24829

PR: https://git.openjdk.org/jdk/pull/24829

From pminborg at openjdk.org  Wed Apr 23 17:07:16 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 23 Apr 2025 17:07:16 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
In-Reply-To: 
References: 
Message-ID: 

On Wed, 23 Apr 2025 14:05:58 GMT, Per Minborg  wrote:

> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
> 
> Re-allocated segments are not zeroed between allocations.

Here are the current benchmark results:


Benchmark                            (ELEM_SIZE)  Mode  Cnt   Score   Error  Units
BufferStackBench.OfVirtual.buffer              8  avgt   15  12.653 ? 0.180  ns/op
BufferStackBench.OfVirtual.buffer             16  avgt   15  12.573 ? 0.121  ns/op
BufferStackBench.OfVirtual.buffer             32  avgt   15  12.712 ? 0.252  ns/op
BufferStackBench.OfVirtual.confined            8  avgt   15  22.714 ? 0.146  ns/op
BufferStackBench.OfVirtual.confined           16  avgt   15  24.269 ? 1.079  ns/op
BufferStackBench.OfVirtual.confined           32  avgt   15  25.519 ? 0.219  ns/op
BufferStackBench.buffer                        8  avgt   15   4.866 ? 0.141  ns/op
BufferStackBench.buffer                       16  avgt   15   4.829 ? 0.106  ns/op
BufferStackBench.buffer                       32  avgt   15   4.809 ? 0.071  ns/op
BufferStackBench.confined                      8  avgt   15  22.768 ? 0.448  ns/op
BufferStackBench.confined                     16  avgt   15  23.380 ? 0.192  ns/op
BufferStackBench.confined                     32  avgt   15  25.874 ? 1.129  ns/op


and


Benchmark                              Mode  Cnt   Score   Error  Units
CallOverheadByValue.OfVirtual.byPtr    avgt   15   4.140 ? 0.054  ns/op
CallOverheadByValue.OfVirtual.byValue  avgt   15  16.698 ? 0.347  ns/op
CallOverheadByValue.byPtr              avgt   15   4.120 ? 0.028  ns/op
CallOverheadByValue.byValue            avgt   15  11.828 ? 0.082  ns/op

> Can we just cleanly revert commit [7764742](https://github.com/openjdk/jdk/commit/77647421c5b13738f6fa145bf30cbb9dd741e164)?
> This new version defines redundant sealed interface + record - feels unnecessary to me.
> Meanwhile, the BufferStackBench is valueable, but its addition should be kept in a separate commit to make reviewing easier.

The idea was to use records for trusted components and less boilerplate. The idea with the interface was to hide the record accessors a bit.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2824439716
PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2824676176

From smarks at openjdk.org  Wed Apr 23 17:17:00 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 23 Apr 2025 17:17:00 GMT
Subject: RFR: 8350703: Add standard system property stdin.encoding [v2]
In-Reply-To: 
References: 
Message-ID: 

> * Windows and Unix: set sprops.stdin_encoding if connected to a console
> * Add specs for stdin.encoding
> * Adjust specs to change "undefined" to "unspecified"
> * Rewrite System.in spec to refer to new property and to clarify usage with classes that perform encoding
> * Update property test

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Update sun.stdout/err.encoding comments; tweak Windows file handle variable name.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24738/files
  - new: https://git.openjdk.org/jdk/pull/24738/files/42933bc2..5357e504

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24738&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24738&range=00-01

  Stats: 13 lines in 2 files changed: 0 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/24738.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24738/head:pull/24738

PR: https://git.openjdk.org/jdk/pull/24738

From smarks at openjdk.org  Wed Apr 23 17:17:01 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 23 Apr 2025 17:17:01 GMT
Subject: RFR: 8350703: Add standard system property stdin.encoding
In-Reply-To: 
References: 
Message-ID: <4_gz6qbqUvaQ9Oc436jEdumIzFr1xHiR79dyooNfhNM=.29203f20-4525-4a28-8cd1-60d667627293@github.com>

On Thu, 17 Apr 2025 18:59:33 GMT, Stuart Marks  wrote:

> * Windows and Unix: set sprops.stdin_encoding if connected to a console
> * Add specs for stdin.encoding
> * Adjust specs to change "undefined" to "unspecified"
> * Rewrite System.in spec to refer to new property and to clarify usage with classes that perform encoding
> * Update property test

OK thanks. Working on the CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24738#issuecomment-2824990439

From smarks at openjdk.org  Wed Apr 23 17:17:02 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 23 Apr 2025 17:17:02 GMT
Subject: RFR: 8350703: Add standard system property stdin.encoding [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 23 Apr 2025 12:54:29 GMT, Alan Bateman  wrote:

>> src/java.base/share/classes/jdk/internal/util/SystemProps.java line 92:
>> 
>>> 90: 
>>> 91:         // Encoding properties for stdin, stdout, and stderr. For stdout and stderr,
>>> 92:         // check "sun.*.encoding" properties before falling back to the
>> 
>> Could explain about sun* a bit more (just for compatibility) and stdin.encoding is free from it.
>
> I think the comment could be clearer. As I understand it, it's just trying to saying that the legacy sun.stdout.encoding/sun.stderr.encoding properties for stdout/stderr only, no equivalent for stdin.

Yeah the comment was a bit terse so I tried to clarify it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24738#discussion_r2056537148

From smarks at openjdk.org  Wed Apr 23 17:17:04 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 23 Apr 2025 17:17:04 GMT
Subject: RFR: 8350703: Add standard system property stdin.encoding [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 01:34:42 GMT, Naoto Sato  wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update sun.stdout/err.encoding comments; tweak Windows file handle variable name.
>
> src/java.base/windows/native/libjava/java_props_md.c line 637:
> 
>> 635: 
>> 636:         {
>> 637:             HANDLE hStdIn;
> 
> Instead of creating a new variable, `hStdOutErr` could be reused with a proper name.

OK I merged the local variables into a single one named `hStdHandle`. I'm not sure that's the best name. I surmise that the `h` prefix is "Hungarian Notation" to indicate that it's a handle, though it makes the name kind of redundant.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24738#discussion_r2056539283

From erikj at openjdk.org  Wed Apr 23 17:17:47 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 23 Apr 2025 17:17:47 GMT
Subject: RFR: 8355249: Remove the use of WMIC from the entire source code
 [v2]
In-Reply-To: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com>
References: 
 <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com>
Message-ID: 

On Tue, 22 Apr 2025 07:41:43 GMT, Daishi Tabata  wrote:

>> After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI.
>> 
>> The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency.
>> 
>> Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file.
>> Note: In my environment, it worked correctly even without these options.
>> 
>> The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in:
>> 
>> - `environment.html`: `windows/system/os` section
>> - `process.html`: `[Process ID]/windows/native/info` section
>> 
>> **Testing:**
>> I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes.
>
> Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   run jcheck

I verified that the makefile, configure and failure_handler changes are working in our internal test system. I can't review the jpackage changes.

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24791#pullrequestreview-2788157583

From alanb at openjdk.org  Wed Apr 23 17:38:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Apr 2025 17:38:57 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 23 Apr 2025 15:18:49 GMT, Viktor Klang  wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding a releaseFence() to ConcurrentskipListSet.clone()
>
> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListSet.java line 182:
> 
>> 180:             clone.setMap(new ConcurrentSkipListMap(m));
>> 181:             // Needed to ensure safe publication of setMap()
>> 182:             VarHandle.releaseFence();
> 
> @DougLea This might be interesting to you. ?

I wonder if we could just change it to return `new ConcurrentSkipListSet<>(m)`. COWAL could be changed to return a new object too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24821#discussion_r2056578605

From bchristi at openjdk.org  Wed Apr 23 17:45:29 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 23 Apr 2025 17:45:29 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v9]
In-Reply-To: 
References: 
Message-ID: <3mpYb0Tbl6fXTgGr0DkYQGqWLQBItkHUse6gZPba_Kc=.da395d35-6f8d-42a7-8042-3b75088505a8@github.com>

> Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead to intermittent test failures ([JDK-8298783](https://bugs.openjdk.org/browse/JDK-8298783)  is a recent example).
> 
> A better mechanism already exists in the private `Reference.waitForReferenceProcessing()` method. This PR makes `waitForReferenceProcessing()` available to tests via the `WhiteBox` and `ForceGC` test libraries.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  t -> e

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24527/files
  - new: https://git.openjdk.org/jdk/pull/24527/files/316800ae..71df85e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24527&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24527&range=07-08

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24527/head:pull/24527

PR: https://git.openjdk.org/jdk/pull/24527

From bchristi at openjdk.org  Wed Apr 23 17:45:29 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 23 Apr 2025 17:45:29 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v8]
In-Reply-To: <8SJQ-BKC1er-93wOIx-u4NZXx5f5XAqzirLqIYhwDNk=.11200bdd-f6fe-45fb-919e-410a6e7e6ae9@github.com>
References: 
 
 <8SJQ-BKC1er-93wOIx-u4NZXx5f5XAqzirLqIYhwDNk=.11200bdd-f6fe-45fb-919e-410a6e7e6ae9@github.com>
Message-ID: 

On Wed, 23 Apr 2025 06:08:59 GMT, Kim Barrett  wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   make waitForReferenceProcessingMethod volatile
>
> test/lib/jdk/test/whitebox/WhiteBox.java line 605:
> 
>> 603:         throw (InterruptedException) cause;
>> 604:       } else {
>> 605:         throw new RuntimeException(e);
> 
> I still think it would be better to finish unwrapping e, rather than further
> wrapping it. We know the only checked exception is InterruptedException,
> because we checked that when looking up the method. That leaves either
> RuntimeException or Error. I think it is generally inappropriate to wrap
> Errors, and we don't really need to additionally wrap the RuntimeException
> case. But I'm going to approve this change anyway, and leave that question to
> real Java programmers.

For production code, I might do more.
But for a test library (where, IMO, the exception handling path won't see much action), doing enough to get the information into the test log seems sufficient to me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24527#discussion_r2056588317

From liach at openjdk.org  Wed Apr 23 17:56:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Apr 2025 17:56:43 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 23 Apr 2025 17:36:25 GMT, Alan Bateman  wrote:

>> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListSet.java line 182:
>> 
>>> 180:             clone.setMap(new ConcurrentSkipListMap(m));
>>> 181:             // Needed to ensure safe publication of setMap()
>>> 182:             VarHandle.releaseFence();
>> 
>> @DougLea This might be interesting to you. ?
>
> I wonder if we could just change it to return `new ConcurrentSkipListSet<>(m)`. COWAL could be changed to return a new object too.

The set only has a map field, and AbstractSet does not define any additional field. The map should be fine too - two fields in AbstractMap are cleared when cloning happens, so recreating a map from a constructor should have the same effect. (Note a significant field `head` is not cleared upon clone, but seems immediately replaced later in `buildFromSorted`). Both should still be fine with this new return values.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24821#discussion_r2056616868

From smarks at openjdk.org  Wed Apr 23 18:02:56 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 23 Apr 2025 18:02:56 GMT
Subject: RFR: 8350703: Add standard system property stdin.encoding [v3]
In-Reply-To: 
References: 
Message-ID: 

> * Windows and Unix: set sprops.stdin_encoding if connected to a console
> * Add specs for stdin.encoding
> * Adjust specs to change "undefined" to "unspecified"
> * Rewrite System.in spec to refer to new property and to clarify usage with classes that perform encoding
> * Update property test

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Yet another minor bit of wordsmithing.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24738/files
  - new: https://git.openjdk.org/jdk/pull/24738/files/5357e504..c4bf316d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24738&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24738&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24738.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24738/head:pull/24738

PR: https://git.openjdk.org/jdk/pull/24738

From duke at openjdk.org  Wed Apr 23 18:08:49 2025
From: duke at openjdk.org (Johannes Graham)
Date: Wed, 23 Apr 2025 18:08:49 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v13]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
Message-ID: 

On Wed, 23 Apr 2025 16:52:29 GMT, Brian Burkhalter  wrote:

>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8354724: Improve test per reviewer comments

src/java.base/share/classes/java/io/Reader.java line 212:

> 210: 
> 211:             public String readAllChars() throws IOException {
> 212:                 return cs.toString();

Should this be returning a substring of `cs` starting  at `next`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2056635722

From vlivanov at openjdk.org  Wed Apr 23 18:15:10 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 23 Apr 2025 18:15:10 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v12]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 23 Apr 2025 08:43:47 GMT, Hamlin Li  wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 288:
>> 
>>> 286:                   IntFunction> implSupplier,
>>> 287:                   V v) {
>>> 288:         var entry = lookup(op, opc, vspecies, implSupplier);
>> 
>> Seems there is another issue for riscv here.
>> If the rvv extension is not supported on the running machine, it will still generate the code using rvv, this should lead to a crash at runtime?
>
> In previous code, we use `UseRVV` to detect if rvv extension is supported.
> 
> On the other hand, user can choose to disable UseRVV if they want even if rvv extension is supported on the running machine. In this sense, there could be similar issue on other platforms?

Does the following check catch `UseRVV == false` case on RISC-V? 

public boolean isSupported(Operator op, VectorSpecies vspecies) {
...
            int maxLaneCount = VectorSupport.getMaxLaneCount(vspecies.elementType());
            if (vspecies.length() > maxLaneCount) {
                return false; // lacking vector support
            }
...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2056642914

From alanb at openjdk.org  Wed Apr 23 18:59:41 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Apr 2025 18:59:41 GMT
Subject: RFR: 8350703: Add standard system property stdin.encoding [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 18:02:56 GMT, Stuart Marks  wrote:

>> * Windows and Unix: set sprops.stdin_encoding if connected to a console
>> * Add specs for stdin.encoding
>> * Adjust specs to change "undefined" to "unspecified"
>> * Rewrite System.in spec to refer to new property and to clarify usage with classes that perform encoding
>> * Update property test
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Yet another minor bit of wordsmithing.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24738#pullrequestreview-2788428787

From alanb at openjdk.org  Wed Apr 23 18:59:43 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Apr 2025 18:59:43 GMT
Subject: RFR: 8350703: Add standard system property stdin.encoding [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: <_uNWenXFNLg-fNE2xiDFVpGXZceeuxa7XNeMe053Y80=.ff0b300a-579c-452e-8616-30427f76641c@github.com>

On Wed, 23 Apr 2025 17:12:07 GMT, Stuart Marks  wrote:

>> I think the comment could be clearer. As I understand it, it's just trying to saying that the legacy sun.stdout.encoding/sun.stderr.encoding properties for stdout/stderr only, no equivalent for stdin.
>
> Yeah the comment was a bit terse so I tried to clarify it.

Thanks, it looks okay now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24738#discussion_r2056712967

From bpb at openjdk.org  Wed Apr 23 19:09:57 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Apr 2025 19:09:57 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v13]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
Message-ID: 

On Wed, 23 Apr 2025 18:06:27 GMT, Johannes Graham  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8354724: Improve test per reviewer comments
>
> src/java.base/share/classes/java/io/Reader.java line 212:
> 
>> 210: 
>> 211:             public String readAllChars() throws IOException {
>> 212:                 return cs.toString();
> 
> Should this be returning a substring of `cs` starting  at `next`? Also likely needs a `ensureOpen`

You are correct on both counts. That was pretty lame on my part. Will update. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2056729165

From duke at openjdk.org  Wed Apr 23 20:58:48 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 23 Apr 2025 20:58:48 GMT
Subject: RFR: 8333377: Migrate Generic Signature parsing to ClassFile API
 [v6]
In-Reply-To: 
References: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com>
 
Message-ID: 

On Wed, 9 Apr 2025 15:34:25 GMT, Chen Liang  wrote:

>> Core reflection's generic signature parsing uses an ancient library with outdated visitor pattern on a tree model and contains unnecessary boilerplates. This is a duplication of ClassFile API's signature model. We should just move to ClassFile API, which is more throughoutly tested as well.
>> 
>> To ensure compatibility, new tests are added to ensure consistent behavior when encountering malformed signatures or signatures with missing types. The reflective objects have been preserved and the only change is that lazy expansion now happens from CF objects, to reduce compatibility risks.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info
>  - Improve BytecodeDescriptor error message
>  - Years, test facelift
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info
>  - 8333377: Migrate Generic Signature parsing to ClassFile API

src/java.base/share/classes/sun/reflect/generics/info/ClassGenericInfo.java line 1:

> 1: /*

Given?that this?basically rewrites most?of?`sun.reflect.generics.*`, I?feel?like it?might be?better to?just move?these new?files to?`jdk.internal.reflect.generics.*`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19281#discussion_r2056085416

From duke at openjdk.org  Wed Apr 23 21:17:51 2025
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Wed, 23 Apr 2025 21:17:51 GMT
Subject: RFR: 8355335: Avoid pattern matching switches in core ClassFile
 API
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Apr 2025 23:28:38 GMT, Chen Liang  wrote:

> A few pattern matching switches exist in the core parts of ClassFile API responsible for transformations and parsing. They are likely to be used in early bootstrap, and pattern matching switches require bootstrap methods, which depend on core ClassFile API.
> 
> For example, currently BlockCodeBuilderImpl prevents BlockCodeBuilder from being used in early bootstrap; luckily we are currently all using manual labels, and as a result this does not surface in lambdas.

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24807#pullrequestreview-2788699872

From liach at openjdk.org  Wed Apr 23 21:43:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Apr 2025 21:43:02 GMT
Subject: RFR: 8355335: Avoid pattern matching switches in core ClassFile
 API
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Apr 2025 23:28:38 GMT, Chen Liang  wrote:

> A few pattern matching switches exist in the core parts of ClassFile API responsible for transformations and parsing. They are likely to be used in early bootstrap, and pattern matching switches require bootstrap methods, which depend on core ClassFile API.
> 
> For example, currently BlockCodeBuilderImpl prevents BlockCodeBuilder from being used in early bootstrap; luckily we are currently all using manual labels, and as a result this does not surface in lambdas.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24807#issuecomment-2825558272

From liach at openjdk.org  Wed Apr 23 21:43:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Apr 2025 21:43:03 GMT
Subject: Integrated: 8355335: Avoid pattern matching switches in core ClassFile
 API
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Apr 2025 23:28:38 GMT, Chen Liang  wrote:

> A few pattern matching switches exist in the core parts of ClassFile API responsible for transformations and parsing. They are likely to be used in early bootstrap, and pattern matching switches require bootstrap methods, which depend on core ClassFile API.
> 
> For example, currently BlockCodeBuilderImpl prevents BlockCodeBuilder from being used in early bootstrap; luckily we are currently all using manual labels, and as a result this does not surface in lambdas.

This pull request has now been integrated.

Changeset: ffe6a4f9
Author:    Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/ffe6a4f9e1449ce9a78372f11bfc0ef6cd7d6842
Stats:     35 lines in 6 files changed: 4 ins; 7 del; 24 mod

8355335: Avoid pattern matching switches in core ClassFile API

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/24807

From liach at openjdk.org  Wed Apr 23 21:43:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Apr 2025 21:43:03 GMT
Subject: RFR: 8354899: Reduce overhead associated with type switches [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Apr 2025 17:20:15 GMT, Chen Liang  wrote:

>> The downcallHandle method in Linker has a complex implementation, and type switches is triggered in multiple places in that handle.
>> 
>> After bytestacks analysis of a simple program that links the native implementation of Class::forName0, it turns out that:
>> 1. there are a few missed usages of type switch in ClassFile API
>> 2. type switch can speed up generation by using explicit stack maps, as stack map gen is over 50% of the generation instructions because the switch is branch-heavy, but the frames are actually simple.
>> 
>> These two combined are not that significant in the overall overhead of downcallHandle, but would be helpful for other workloads.
>
> 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:
> 
>  - Rollback classfile boot speed changes
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/switch-gen-speed
>  - Fix adding potentially unbound labels
>  - 8354899: Reduce overhead associated with type switches

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24705#issuecomment-2825558849

From liach at openjdk.org  Wed Apr 23 21:43:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Apr 2025 21:43:04 GMT
Subject: Integrated: 8354899: Reduce overhead associated with type switches
In-Reply-To: 
References: 
Message-ID: <-aXZjdfMnvBx5KldN_ax-rjwrQOxCtOruIKNshpG9UA=.8848efce-aa79-497c-bca4-04ff1175ff3c@github.com>

On Thu, 17 Apr 2025 00:08:55 GMT, Chen Liang  wrote:

> The downcallHandle method in Linker has a complex implementation, and type switches is triggered in multiple places in that handle.
> 
> After bytestacks analysis of a simple program that links the native implementation of Class::forName0, it turns out that:
> 1. there are a few missed usages of type switch in ClassFile API
> 2. type switch can speed up generation by using explicit stack maps, as stack map gen is over 50% of the generation instructions because the switch is branch-heavy, but the frames are actually simple.
> 
> These two combined are not that significant in the overall overhead of downcallHandle, but would be helpful for other workloads.

This pull request has now been integrated.

Changeset: bd1c53e9
Author:    Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/bd1c53e96038994788ca5c11602aa2ce4fa4c840
Stats:     47 lines in 2 files changed: 34 ins; 2 del; 11 mod

8354899: Reduce overhead associated with type switches

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/24705

From liach at openjdk.org  Wed Apr 23 21:45:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Apr 2025 21:45:53 GMT
Subject: RFR: 8333377: Migrate Generic Signature parsing to ClassFile API
 [v6]
In-Reply-To: 
References: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com>
 
 
Message-ID: <14GGFm6qnc-5wbfcf8kio9DAd1R1dR9jQs8Hvu2-8Bw=.d264d166-657b-4a66-95b1-749d91a5f743@github.com>

On Wed, 23 Apr 2025 13:39:40 GMT, ExE Boss  wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info
>>  - Improve BytecodeDescriptor error message
>>  - Years, test facelift
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info
>>  - 8333377: Migrate Generic Signature parsing to ClassFile API
>
> src/java.base/share/classes/sun/reflect/generics/info/ClassGenericInfo.java line 1:
> 
>> 1: /*
> 
> Given?that this?basically rewrites most?of?`sun.reflect.generics.*`, I?feel?like it?might be?better to?just move?these new?files to?`jdk.internal.reflect.generics.*`.

We should, in fact, remove as much legacy `sun` packages as possible - for the particular package name choice, I think `jdk.internal.reflect.type` might be better, as we are really reflecting on language types. But I think that effort will get its own ticket.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19281#discussion_r2056908805

From bpb at openjdk.org  Wed Apr 23 21:50:46 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Apr 2025 21:50:46 GMT
Subject: RFR: 8354450: Using a File with a path containing a trailing space
 should fail when alternative data streams are disabled (win) [v4]
In-Reply-To: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
References: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
Message-ID: <49Yvff-cNfqJxpzHD6NThf3zH46MivdDcKn0axoNEjc=.e5971545-10dc-4d56-b006-8e0409a179bc@github.com>

> In `java.io.WinNTFileSystem::isInvalid`, replace an insufficient test for file path validity with a sufficient test for file path invalidity. Also, add a new test.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8354450: Simplify test for " \" in path elements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24635/files
  - new: https://git.openjdk.org/jdk/pull/24635/files/624f4f79..34f7933d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24635&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24635&range=02-03

  Stats: 12 lines in 1 file changed: 0 ins; 6 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24635.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24635/head:pull/24635

PR: https://git.openjdk.org/jdk/pull/24635

From bpb at openjdk.org  Wed Apr 23 22:04:25 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Apr 2025 22:04:25 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v13]
In-Reply-To: 
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
 
 
Message-ID: 

On Wed, 23 Apr 2025 18:06:27 GMT, Johannes Graham  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8354724: Improve test per reviewer comments
>
> src/java.base/share/classes/java/io/Reader.java line 212:
> 
>> 210: 
>> 211:             public String readAllChars() throws IOException {
>> 212:                 return cs.toString();
> 
> Should this be returning a substring of `cs` starting  at `next`? Also likely needs a `ensureOpen`

Fixed in dc84bd1 and updated test to verify `cs` starting at `next`. Thanks @j3graham for catching it!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2056926309

From bpb at openjdk.org  Wed Apr 23 22:04:25 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Apr 2025 22:04:25 GMT
Subject: RFR: 8354724: BufferedReader readAllLines and readString methods
 [v14]
In-Reply-To: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
References: <62XHAKfASefMmwtyJUPzNTSa7pCD9W0Sc693w-_YahU=.06096a35-9140-47db-a3c0-123f9e5020f1@github.com>
Message-ID: 

> Implement the requested methods and add a test thereof.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8354724: Fix readAllChars gaffe in Reader returned by Readed.of and account for it in test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24728/files
  - new: https://git.openjdk.org/jdk/pull/24728/files/edb813da..dc84bd1b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24728&range=12-13

  Stats: 7 lines in 2 files changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24728/head:pull/24728

PR: https://git.openjdk.org/jdk/pull/24728

From almatvee at openjdk.org  Wed Apr 23 22:27:59 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 23 Apr 2025 22:27:59 GMT
Subject: RFR: 8355328: Improve negative tests coverage for jpackage signing
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 02:30:59 GMT, Alexey Semenyuk  wrote:

>> Add tests covering `error.explicit-sign-no-cert` error ID to ErrorTest.
>> 
>> If signing identity validation fails, jpackage outputs three messages constructed from the following string IDs: `error.cert.not.found`, `error.explicit-sign-no-cert`, and `error.explicit-sign-no-cert.advice`.
>> 
>> `TKit.TextStreamVerifier.andThen()` method doesn't work correctly when combining more than two instances of `TKit.TextStreamVerifier` class. To address this bug and analyze jpackage's output for three expected strings when a non-existent signing identity is specified, the `TKit.TextStreamVerifier.andThen()` method was replaced with the `TKit.TextStreamVerifier.Group` class. Changes in other tests are a result of this change.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace

Marked as reviewed by almatvee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24786#pullrequestreview-2788796519

From asemenyuk at openjdk.org  Wed Apr 23 22:33:11 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 23 Apr 2025 22:33:11 GMT
Subject: Integrated: 8355328: Improve negative tests coverage for jpackage
 signing
In-Reply-To: 
References: 
Message-ID: <83UzKAvzc9InAGB196t88Wnxp9-eIxW2YyBRglvK340=.a5ee4767-b7d1-4029-b61c-71843a4ca24e@github.com>

On Tue, 22 Apr 2025 00:43:24 GMT, Alexey Semenyuk  wrote:

> Add tests covering `error.explicit-sign-no-cert` error ID to ErrorTest.
> 
> If signing identity validation fails, jpackage outputs three messages constructed from the following string IDs: `error.cert.not.found`, `error.explicit-sign-no-cert`, and `error.explicit-sign-no-cert.advice`.
> 
> `TKit.TextStreamVerifier.andThen()` method doesn't work correctly when combining more than two instances of `TKit.TextStreamVerifier` class. To address this bug and analyze jpackage's output for three expected strings when a non-existent signing identity is specified, the `TKit.TextStreamVerifier.andThen()` method was replaced with the `TKit.TextStreamVerifier.Group` class. Changes in other tests are a result of this change.

This pull request has now been integrated.

Changeset: 669d4d6b
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/669d4d6bfa50ab6ae73d05c6a0b069f4507d298e
Stats:     188 lines in 19 files changed: 117 ins; 18 del; 53 mod

8355328: Improve negative tests coverage for jpackage signing

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/24786

From liach at openjdk.org  Wed Apr 23 22:45:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Apr 2025 22:45:41 GMT
Subject: RFR: 8297727: Forcing LF interpretation lead to StackOverflowError in
 reflection code
Message-ID: <92SXp91ulmlGXdPzA4fm7FwYDNiSE-_dEVzmJIf_Ahc=.4f3667c2-59df-4cca-b66f-8036ba871e57@github.com>

When LambdaForms are interpreted, so are field lambda forms. When this happens, we may get into an infinite recursion due to field lambda forms using `MethodHandleStatics.UNSAFE` via field lambda form.

I think the best solution here is to always eagerly compile field DMH forms - we already do so for all method forms, and there is a finite number of field forms, mostly pregenerated. The reference with cast form is erroneously missed, and it is actually the culprit of this issue. Will pregenerate that in another patch.

-------------

Commit messages:
 - 8297727: Forcing LF interpretation lead to StackOverflowError in reflection code

Changes: https://git.openjdk.org/jdk/pull/24835/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24835&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297727
  Stats: 53 lines in 2 files changed: 45 ins; 8 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24835.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24835/head:pull/24835

PR: https://git.openjdk.org/jdk/pull/24835

From ascarpino at openjdk.org  Wed Apr 23 23:30:42 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 23 Apr 2025 23:30:42 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Apr 2025 17:04:56 GMT, Artur Barashev  wrote:

> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check of the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust.

Do we understand why this is so much slower?  I wouldn't have thought extra checking would cause this big of a performance hit.

test/jdk/sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java line 147:

> 145: 
> 146:         KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
> 147:         kpg.initialize(2048);

I would not specify the key size and let the provider default set it. That could expose any problems between constraints and provider defaults, also it future proofs the test when key sizes are increased some day in the future.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24756#pullrequestreview-2788272968
PR Review Comment: https://git.openjdk.org/jdk/pull/24756#discussion_r2056617930

From vlivanov at openjdk.org  Wed Apr 23 23:54:01 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 23 Apr 2025 23:54:01 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v13]
In-Reply-To: 
References: 
Message-ID: 

> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
> 
> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
> 
> The patch consists of the following parts:
>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
> 
> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
> 
> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
> 
> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
> 
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
> 
> Thanks!

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  CPUFeatures: RISC-V support

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24462/files
  - new: https://git.openjdk.org/jdk/pull/24462/files/42ed9baa..585312ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=11-12

  Stats: 5 lines in 2 files changed: 1 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24462/head:pull/24462

PR: https://git.openjdk.org/jdk/pull/24462

From vlivanov at openjdk.org  Wed Apr 23 23:54:02 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 23 Apr 2025 23:54:02 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v10]
In-Reply-To: <4LfzOzPmZZ42Aoub8uPvjvAvUjD29tr54PyNQMGSEEM=.fd73d966-b7cc-4695-a79f-fd3c62467ed0@github.com>
References: 
 
 
 
 <4c9BdDJr1BWA92Uv7HHIa6_ons9yzW0U6q0uOzKLxPY=.102b7ec5-c4bb-4117-a092-0815d01aa74d@github.com>
 <4LfzOzPmZZ42Aoub8uPvjvAvUjD29tr54PyNQMGSEEM=.fd73d966-b7cc-4695-a79f-fd3c62467ed0@github.com>
Message-ID: <2DFsGhESxoFOqtDvZhoA24gyQkTu1xU_MgKCxdkCd2w=.49767c67-7ca4-40e1-8c0c-f7a4ce44f2e0@github.com>

On Wed, 23 Apr 2025 08:54:23 GMT, Hamlin Li  wrote:

>> The intention is to align `_features_string` with `_features` which enumerates well-known CPU capabilities JVM manages. As of now, `_features_string` contains more information, so I introduced `_cpu_info_string` to keep it.
>> 
>> Speaking of `test/lib/jdk/test/whitebox/cpuinfo/CPUInfo.java`, the approach chosen there may be fine for a test library, but we need a more stable API between JVM and JDK.
>
> I'm fine with this.
> But it might be better to change the spliting regex of  `_features_string` in CPUFeatures.java to support riscv cpu features format.

Ok, I pushed an update. Let me know what you think about it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2057061162

From vlivanov at openjdk.org  Wed Apr 23 23:58:43 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 23 Apr 2025 23:58:43 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v12]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Wed, 23 Apr 2025 18:11:42 GMT, Vladimir Ivanov  wrote:

>> In previous code, we use `UseRVV` to detect if rvv extension is supported.
>> 
>> On the other hand, user can choose to disable UseRVV if they want even if rvv extension is supported on the running machine. In this sense, there could be similar issue on other platforms?
>
> Does the following check catch `UseRVV == false` case on RISC-V? 
> 
> public boolean isSupported(Operator op, VectorSpecies vspecies) {
> ...
>             int maxLaneCount = VectorSupport.getMaxLaneCount(vspecies.elementType());
>             if (vspecies.length() > maxLaneCount) {
>                 return false; // lacking vector support
>             }
> ...

FTR both `VectorSupport.getMaxLaneCount()` and `CPUFeatures` don't rely on  raw list of ISA extensions CPU supports, but only those reported by the JVM. So, if some feature support is disabled on JVM side, it won't be reported by `VM_Version` and, hence, `CPUFeatures`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2057065571

From liach at openjdk.org  Thu Apr 24 00:14:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Apr 2025 00:14:59 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v53]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 10 Apr 2025 12:31:04 GMT, Viktor Klang  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve docs as per comments
>
> src/java.base/share/classes/java/lang/StableValue.java line 357:
> 
>> 355:  *
>> 356:  * If there are circular dependencies in a dependency graph, a stable value will
>> 357:  * eventually throw an {@linkplain IllegalStateException} upon referencing elements in
> 
> Suggestion:
> 
>  * eventually throw an {@linkplain IllegalStateException} upon detecting

Keep this suggestion alive

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2057075086

From liach at openjdk.org  Thu Apr 24 00:15:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Apr 2025 00:15:02 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v76]
In-Reply-To: 
References: 
 
Message-ID: <19m8VVGx2FHmrfgvPtIMS_FRgyURFEfaaJjN4rMg018=.0dd1639c-0147-4c41-a18c-c020477d51d0@github.com>

On Wed, 23 Apr 2025 12:12:26 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace 'contents' with 'result' in the docs

src/java.base/share/classes/java/lang/StableValue.java line 433:

> 431:  *           provide transitive constantness.
> 432:  *
> 433:  * @implNote Stable values, functions, and collections are not {@link Serializable}.

Suggestion:

 *           

 *           Stable values, functions, and collections are not {@link Serializable}.

src/java.base/share/classes/java/util/Collection.java line 61:

> 59:  * implementations in the Java platform libraries comply.
> 60:  *
> 61:  * 
Certain methods are specified to be

Suggestion:

 * 
Certain methods are specified to be

src/java.base/share/classes/java/util/ImmutableCollections.java line 1616:

> 1614:         }
> 1615: 
> 1616:         final class StableMapValues extends AbstractCollection {

Can this be `AbstractImmutableCollection`? I know we have #18522 debate going on, but we can probably safely port the semantics introduced in that PR to new collections we add in this patch.

src/java.base/share/classes/java/util/ReverseOrderListView.java line 305:

> 303:             final StableValueImpl[] reversed = ArraysSupport.reverse(
> 304:                     Arrays.copyOf(stableList.delegates, stableList.delegates.length));
> 305:             return StableUtil.renderElements(base, "Collection", reversed);

StableList should provide its own SubList class that provide this implementation, instead of hacking the general-purpose view.

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 85:

> 83:         LANGUAGE_MODEL,
> 84:         @JEP(number = 502, title = "Stable Values", status = "Preview")
> 85:         STABLE_VALUES,

Please add your enum constant above `LANGUAGE_MODEL` - it is a reserved key for certain reflective preview APIs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2057076154
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2057074429
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2057073986
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2057071480
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2057069964

From bpb at openjdk.org  Thu Apr 24 00:37:57 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 24 Apr 2025 00:37:57 GMT
Subject: RFR: 8355443: [java.io] Use @requires tag instead of exiting based on
 File.separatorChar value
Message-ID: 

For tests of the `java.io` package, instead of doing this

    public static void main(String[] args) throws Exception {
        if (File.separatorChar != '\') {
            /* This test is only valid on win32 systems */
            return;
        }

do this

   @requires (os.family == "windows")

-------------

Commit messages:
 - 8355443: [java.io] Use @requires tag instead of exiting based on File.separatorChar value

Changes: https://git.openjdk.org/jdk/pull/24838/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24838&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355443
  Stats: 62 lines in 10 files changed: 10 ins; 35 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/24838.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24838/head:pull/24838

PR: https://git.openjdk.org/jdk/pull/24838

From xgong at openjdk.org  Thu Apr 24 01:46:42 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 24 Apr 2025 01:46:42 GMT
Subject: RFR: 8351623: VectorAPI: Refactor subword gather load and add SVE
 implementation
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Apr 2025 01:42:22 GMT, Xiaohong Gong  wrote:

>> ### Summary:
>> [JDK-8318650](http://java-service.client.nvidia.com/?q=8318650) added the hotspot intrinsifying of subword gather load APIs for X86 platforms [1]. This patch aims at implementing the equivalent functionality for AArch64 SVE platform. In addition to the AArch64 backend support, this patch also refactors the API implementation in Java side and the compiler mid-end part to make the operations more efficient and maintainable across different architectures.
>> 
>> ### Background:
>> Vector gather load APIs load values from memory addresses calculated by adding a base pointer to integer indices stored in an int array. SVE provides native vector gather load instructions for byte/short types using an int vector saving indices (see [2][3]).
>> 
>> The number of loaded elements must match the index vector's element count. Since int elements are 4/2 times larger than byte/short elements, and given `MaxVectorSize` constraints, the operation may need to be splitted into multiple parts.
>> 
>> Using a 128-bit byte vector gather load as an example, there are four scenarios with different `MaxVectorSize`:
>> 
>> 1. `MaxVectorSize = 16, byte_vector_size = 16`:
>>    - Can load 4 indices per vector register
>>    - So can finish 4 bytes per gather-load operation
>>    - Requires 4 times of gather-loads and final merge
>>    Example:
>>    ```
>>    byte[] arr = [a, b, c, d, e, f, g, h, i, g, k, l, m, n, o, p, ...]
>>    int[] idx = [3, 2, 4, 1, 5, 7, 5, 2, 0, 6, 7, 1, 15, 10, 11, 9]
>> 
>>    4 gather-load:
>>    idx_v1 = [1 4 2 3]    gather_v1 = [0000 0000 0000 becd]
>>    idx_v2 = [2 5 7 5]    gather_v2 = [0000 0000 0000 cfhf]
>>    idx_v3 = [1 7 6 0]    gather_v3 = [0000 0000 0000 bhga]
>>    idx_v4 = [9 11 10 15] gather_v4 = [0000 0000 0000 jlkp]
>>    merge: v = [jlkp bhga cfhf becd]
>>    ```
>> 
>> 2. `MaxVectorSize = 32, byte_vector_size = MaxVectorSize / 2`:
>>    - Can load 8 indices per vector register
>>    - So can finish 8 bytes per gather-load operation
>>    - Requires 2 times of gather-loads and merge
>>    Example:
>>    ```
>>    byte[] arr = [a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, ...]
>>    int[] index = [3, 2, 4, 1, 5, 7, 5, 2, 0, 6, 7, 1, 15, 10, 11, 9]
>> 
>>    2 gather-load:
>>    idx_v1 = [2 5 7 5 1 4 2 3]
>>    idx_v2 = [9 11 10 15 1 7 6 0]
>>    gather_v1 = [0000 0000 0000 0000 0000 0000 cfhf becd]
>>    gather_v2 = [0000 0000 0000 0000 0000 0000 jlkp bhga]
>>    merge: v = [0000 0000 0000 0000 jlkp bhga cfhf becd]
>>    ```
>> 
>> 3. `MaxVectorSize = 64, byte_v...
>
> Hi @jatin-bhateja , could you please help take a look at this PR especially the X86 part? Thanks a lot!
> Hi @RealFYang , could you please help review the RVV part? Thanks a lot!

> @XiaohongGong I had a quick look at your changes and PR description. I wonder if you could split some of the refactoring into a separate PR? That would make it easier to review. Currently, you basically have x64 changes, aarch64 changes, Java library changes, and C2 changes. That's a lot at once. And it would basically require the review from a lot of different people at once.
> 
> Splitting would make it easier to review, less work for the reviewer. It would ensure everybody can look at a smaller change set, and that would also increase the quality of the code after review, I think.
> 
> What do you think?

Thanks for looking at this PR @eme64 ! It's a good idea splitting this PR as smaller ones. I will consider about this. Maybe I can do a refactoring first, and then implement the compiler support for AArch64 as a followed-up PR. WDYT?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24679#issuecomment-2825949426

From kbarrett at openjdk.org  Thu Apr 24 04:35:44 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 24 Apr 2025 04:35:44 GMT
Subject: RFR: 8305186: Reference.waitForReferenceProcessing should be more
 accessible to tests [v9]
In-Reply-To: <3mpYb0Tbl6fXTgGr0DkYQGqWLQBItkHUse6gZPba_Kc=.da395d35-6f8d-42a7-8042-3b75088505a8@github.com>
References: 
 <3mpYb0Tbl6fXTgGr0DkYQGqWLQBItkHUse6gZPba_Kc=.da395d35-6f8d-42a7-8042-3b75088505a8@github.com>
Message-ID: 

On Wed, 23 Apr 2025 17:45:29 GMT, Brent Christian  wrote:

>> Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead to intermittent test failures ([JDK-8298783](https://bugs.openjdk.org/browse/JDK-8298783)  is a recent example).
>> 
>> A better mechanism already exists in the private `Reference.waitForReferenceProcessing()` method. This PR makes `waitForReferenceProcessing()` available to tests via the `WhiteBox` and `ForceGC` test libraries.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   t -> e

Still good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24527#pullrequestreview-2789671056

From epeter at openjdk.org  Thu Apr 24 06:18:02 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 24 Apr 2025 06:18:02 GMT
Subject: RFR: 8351623: VectorAPI: Refactor subword gather load and add SVE
 implementation
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 23 Apr 2025 13:02:31 GMT, Emanuel Peter  wrote:

>> Hi @jatin-bhateja , could you please help take a look at this PR especially the X86 part? Thanks a lot!
>> Hi @RealFYang , could you please help review the RVV part? Thanks a lot!
>
> @XiaohongGong I had a quick look at your changes and PR description. I wonder if you could split some of the refactoring into a separate PR? That would make it easier to review. Currently, you basically have x64 changes, aarch64 changes, Java library changes, and C2 changes. That's a lot at once. And it would basically require the review from a lot of different people at once.
> 
> Splitting would make it easier to review, less work for the reviewer. It would ensure everybody can look at a smaller change set, and that would also increase the quality of the code after review, I think.
> 
> What do you think?

> Thanks for looking at this PR @eme64 ! It's a good idea splitting this PR as smaller ones. I will consider about this. Maybe I can do a refactoring first, and then implement the compiler support for AArch64 as a followed-up PR. WDYT?

That sounds excellent :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24679#issuecomment-2826496942

From vyazici at openjdk.org  Thu Apr 24 08:29:41 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 24 Apr 2025 08:29:41 GMT
Subject: RFR: 8355443: [java.io] Use @requires tag instead of exiting based
 on File.separatorChar value
In-Reply-To: 
References: 
Message-ID: 

On Thu, 24 Apr 2025 00:33:20 GMT, Brian Burkhalter  wrote:

> For tests of the `java.io` package, instead of doing this
> 
>     public static void main(String[] args) throws Exception {
>         if (File.separatorChar != '\') {
>             /* This test is only valid on win32 systems */
>             return;
>         }
> 
> do this
> 
>    @requires (os.family == "windows")

Marked as reviewed by vyazici (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24838#pullrequestreview-2790211663

From pminborg at openjdk.org  Thu Apr 24 09:21:04 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Apr 2025 09:21:04 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v76]
In-Reply-To: <19m8VVGx2FHmrfgvPtIMS_FRgyURFEfaaJjN4rMg018=.0dd1639c-0147-4c41-a18c-c020477d51d0@github.com>
References: 
 
 <19m8VVGx2FHmrfgvPtIMS_FRgyURFEfaaJjN4rMg018=.0dd1639c-0147-4c41-a18c-c020477d51d0@github.com>
Message-ID: 

On Thu, 24 Apr 2025 00:05:04 GMT, Chen Liang  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace 'contents' with 'result' in the docs
>
> src/java.base/share/classes/java/util/Collection.java line 61:
> 
>> 59:  * implementations in the Java platform libraries comply.
>> 60:  *
>> 61:  * 
Certain methods are specified to be
> 
> Suggestion:
> 
>  * 
Certain methods are specified to be

I want to keep the style as the existing one used in other places in the class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2057933419

From pminborg at openjdk.org  Thu Apr 24 09:21:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Apr 2025 09:21:03 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v77]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 370 commits:

 - Revert unwanted changes
 - Merge branch 'master' into implement-jep502
 - Address comments
 - Replace 'contents' with 'result' in the docs
 - Rephrase happens-before clause
 - Replace 'content' with 'contents' and doc updates
 - Merge branch 'master' into implement-jep502
 - Remove section on fun/coll sync
 - Reformat docs
 - Fix failing test (exception message)
 - ... and 360 more: https://git.openjdk.org/jdk/compare/290d24d1...bcc022fe

-------------

Changes: https://git.openjdk.org/jdk/pull/23972/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=76
  Stats: 4807 lines in 30 files changed: 4795 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From duke at openjdk.org  Thu Apr 24 09:34:30 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 24 Apr 2025 09:34:30 GMT
Subject: RFR: 8077587: BigInteger Roots [v28]
In-Reply-To: 
References: 
Message-ID: <_pSRWrdPN6-W-XYQ-9Yrt0kE2-c_fxdypa1xAWyZXyU=.778997e8-d913-4624-9720-ae32aafc00f5@github.com>

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Optimized BigInteger.pow(int) for single-word values

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/f0d06055..f20d19be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=26-27

  Stats: 64 lines in 1 file changed: 55 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From vklang at openjdk.org  Thu Apr 24 09:36:22 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 24 Apr 2025 09:36:22 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v77]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 24 Apr 2025 09:21:03 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 370 commits:
> 
>  - Revert unwanted changes
>  - Merge branch 'master' into implement-jep502
>  - Address comments
>  - Replace 'contents' with 'result' in the docs
>  - Rephrase happens-before clause
>  - Replace 'content' with 'contents' and doc updates
>  - Merge branch 'master' into implement-jep502
>  - Remove section on fun/coll sync
>  - Reformat docs
>  - Fix failing test (exception message)
>  - ... and 360 more: https://git.openjdk.org/jdk/compare/290d24d1...bcc022fe

src/java.base/share/classes/java/util/ImmutableCollections.java line 888:

> 886:         private static final class StableReverseOrderListView extends ReverseOrderListView.Rand {
> 887: 
> 888:             public StableReverseOrderListView(List base) {

public?

src/java.base/share/classes/java/util/ReverseOrderListView.java line 300:

> 298:     public String toString() {
> 299:         Iterator it = iterator();
> 300:         if (! it.hasNext())

Suggestion:

        if (!it.hasNext())

src/java.base/share/classes/java/util/ReverseOrderListView.java line 308:

> 306:             E e = it.next();
> 307:             sb.append(e == this ? "(this Collection)" : e);
> 308:             if (! it.hasNext())

Suggestion:

            if (!it.hasNext())

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2057967620
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2057958943
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2057960785

From eirbjo at openjdk.org  Thu Apr 24 09:37:29 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 24 Apr 2025 09:37:29 GMT
Subject: RFR: 8355475: UNCTest should use an existing UNC path
Message-ID: <47ZQs_0TJ8w9yEHr-1EmMQB_LeHGKQZ1rP8TP_KH1kQ=.5939433d-c7a6-4336-ada7-809dda5c56d9@github.com>

Please review this test-only PR which updates `UNCTest.java` to use a UNC path which is known to exist.

The test currently uses the file URL `file://jdk/LOCAL-JAVA/jdk1.4/win/README.txt`, but since this is unlikely to resolve to an existing UNC path on any CI server, the test doesn't really verify what it's supposed to.

This PR changes the test to instead use the path `file://computername/C$/Windows`, which should always be available unless Administrative Shares has been disabled. We detect this case by using File::exists for the path and simply skip the test if it does not exist.

I forced this test to run in tier1 on GHA and verified that it ran successfully, without being skipped. Meaning Administrative Shares is enabled in the Windows GHA instance.

A test run in Oracle's CI verifying a successful run (without skipping) would be welcome.

This is a test only PR, `noreg-self` has been added in the JBS.

-------------

Commit messages:
 - UNCTest should use an existing UNC path

Changes: https://git.openjdk.org/jdk/pull/24842/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24842&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355475
  Stats: 33 lines in 1 file changed: 30 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24842.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24842/head:pull/24842

PR: https://git.openjdk.org/jdk/pull/24842

From duke at openjdk.org  Thu Apr 24 09:51:42 2025
From: duke at openjdk.org (erifan)
Date: Thu, 24 Apr 2025 09:51:42 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 18 Apr 2025 01:36:10 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 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 'master' into JDK-8354242
>  - 8354242: VectorAPI: combine vector not operation with compare
>    
>    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...

@jatin-bhateja Thanks for your review!

-------------

PR Review: https://git.openjdk.org/jdk/pull/24674#pullrequestreview-2790317981

From duke at openjdk.org  Thu Apr 24 09:51:45 2025
From: duke at openjdk.org (erifan)
Date: Thu, 24 Apr 2025 09:51:45 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 23 Apr 2025 12:09:51 GMT, Jatin Bhateja  wrote:

>> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8354242
>>  - 8354242: VectorAPI: combine vector not operation with compare
>>    
>>    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	...
>
> src/hotspot/share/opto/vectornode.cpp line 2234:
> 
>> 2232:   // XorV/XorVMask is commutative, swap VectorMaskCmp/Op_VectorMaskCast to in1.
>> 2233:   if (in1->Opcode() != Op_VectorMaskCmp && in1->Opcode() != Op_VectorMaskCast) {
>> 2234:     swap(in1, in2);
> 
> Swapping inputs like this without refreshing GVN bookkeeping is not safe. I guess you wanted to use Node::swap_edges.

The edges are not swapped, but two variables in1 and in2

> src/hotspot/share/opto/vectornode.cpp line 2243:
> 
>> 2241:     in1 = in1->in(1);
>> 2242:   }
>> 2243:   if (in1->Opcode() != Op_VectorMaskCmp || in1->outcnt() > 1 ||
> 
> Checks on outcnt on line 2243 and 2238 can be removed. Idealization looks for a specific graph palette and replaces it with a new node whose inputs are the same as the inputs of the palette. GVN will do the retention job if any intermediate node has users beyond the pattern being replaced.

Thanks for telling me this information. Another more important reason to check outcnt here is to prevent this optimization when the uses of VectorMaskCmp is greater than 1, because this optimization may not be worthwhile. For example:


  public static void testVectorMaskCmp() {
    IntVector bv = IntVector.fromArray(I_SPECIES, ib, 0);
    IntVector av = IntVector.fromArray(I_SPECIES, ia, 0);
    VectorMask m1 = av.compare(VectorOperators.NE, bv);  // two uses
    VectorMask m2 =m1.not();
    m1.intoArray(m, 0);
    av.lanewise(VectorOperators.ABS, m2).intoArray(ia, 0);
  }


If we do not check outcnt and still do this optimization, two VectorMaskCmp nodes will be generated, and finally two VectorMaskCmp instructions will be generated. This is unreasonable because VectorMaskCmp has much higher latency than xor instruction on aarch64.

> src/hotspot/share/opto/vectornode.cpp line 2265:
> 
>> 2263:     vmcmp = new VectorMaskCastNode(phase->transform(vmcmp), vmcast_vt);
>> 2264:   }
>> 2265:   return vmcmp;
> 
> It would be preferable if you could kindly re-factor the code such that we only call VectorNode::Ideal once at return to comply with aesthetics of other idealization routines.

Ok, I'll change it in the next commit.

> test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java line 38:
> 
>> 36:  * @summary test combining vector not operation with compare
>> 37:  * @modules jdk.incubator.vector
>> 38:  * @requires ((os.arch!="x86" & os.arch!="i386" & os.arch!="amd64" & os.arch!="x86_64") | vm.cpu.features ~= ".*avx.*")
> 
> You can remove this platform limitation and forward the constraints to @IR rules using applyIfCPUFeatureOr

Since this is a platform independent optimization, I tend to use this `@requires` because it's simpler.  If we use `applyIfCPUFeatureOr`, we need to add the same restriction before each test. In addition, if a new architecture supports the vector node, this test may not cover it. What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2057901771
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2057976512
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2057982231
PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2057993569

From aph at openjdk.org  Thu Apr 24 10:30:50 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 24 Apr 2025 10:30:50 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v2]
In-Reply-To: 
References: 
 
Message-ID: <46g4wcnZe1Hiodlu9pe4VOoE6hzpKz5tousDFKzs8qA=.edca6b56-d299-41de-a714-4f5ad5bdaa6d@github.com>

On Fri, 18 Apr 2025 01:36:10 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 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 'master' into JDK-8354242
>  - 8354242: VectorAPI: combine vector not operation with compare
>    
>    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...

src/hotspot/share/opto/node.cpp line 1226:

> 1224:     // be added to the IGVN worklist, then the optimization will not be applied.
> 1225:     // Therefore, add this node into IGVN worklist to make the optimization happen.
> 1226:     return true;

Suggestion:

  } else if (n->Opcode() == Op_XorV || n->Opcode() == Op_XorVMask) {
    // Condition for removing an unnecessary not() following
    // a compare(...) operation.
    // The predecessor of n (this XorV or XorVMask) may also be used
    // by a useless VectorBox node which will later be eliminated by
    // RemoveUseless. Return true to ensure that subgraph
    // transformations are performed on n.
    return true;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2058061667

From duke at openjdk.org  Thu Apr 24 10:34:13 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 24 Apr 2025 10:34:13 GMT
Subject: RFR: 8077587: BigInteger Roots [v29]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Optimized repeated squaring trick using cache for powers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/f20d19be..8676af7c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=27-28

  Stats: 45 lines in 1 file changed: 18 ins; 0 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From pminborg at openjdk.org  Thu Apr 24 10:37:59 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Apr 2025 10:37:59 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v78]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Make public constuctor private

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/bcc022fe..4839d186

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=77
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=76-77

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From vklang at openjdk.org  Thu Apr 24 10:40:11 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 24 Apr 2025 10:40:11 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v78]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 24 Apr 2025 10:37:59 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make public constuctor private

?

-------------

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23972#pullrequestreview-2790601691

From pminborg at openjdk.org  Thu Apr 24 10:40:13 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Apr 2025 10:40:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v77]
In-Reply-To: 
References: 
 
 
Message-ID: <8yoNVeF2MRJfhLY9LrldD1S3u5iw7n8QvlBXqaY6SMQ=.b8da8a54-3688-4959-a0ed-7d4eb4b92188@github.com>

On Thu, 24 Apr 2025 09:29:14 GMT, Viktor Klang  wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 370 commits:
>> 
>>  - Revert unwanted changes
>>  - Merge branch 'master' into implement-jep502
>>  - Address comments
>>  - Replace 'contents' with 'result' in the docs
>>  - Rephrase happens-before clause
>>  - Replace 'content' with 'contents' and doc updates
>>  - Merge branch 'master' into implement-jep502
>>  - Remove section on fun/coll sync
>>  - Reformat docs
>>  - Fix failing test (exception message)
>>  - ... and 360 more: https://git.openjdk.org/jdk/compare/290d24d1...bcc022fe
>
> src/java.base/share/classes/java/util/ReverseOrderListView.java line 308:
> 
>> 306:             E e = it.next();
>> 307:             sb.append(e == this ? "(this Collection)" : e);
>> 308:             if (! it.hasNext())
> 
> Suggestion:
> 
>             if (!it.hasNext())

Reverted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2058076032

From vklang at openjdk.org  Thu Apr 24 10:41:54 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 24 Apr 2025 10:41:54 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 23 Apr 2025 16:23:00 GMT, Chen Liang  wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding a releaseFence() to ConcurrentskipListSet.clone()
>
> Thanks. We can investigate how clone cleanups interact with truly final or strict finals in another issue.

@liach @AlanBateman My proposal here would be to move forward with the proposed changes for now, and then once 25 is branched off there's an opportunity to take a broader look at `clone()`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24821#issuecomment-2827154019

From pminborg at openjdk.org  Thu Apr 24 11:19:56 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Apr 2025 11:19:56 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 15:22:37 GMT, Viktor Klang  wrote:

>> This Pull Request replaces the uses of Field + setAccessible to modify final fields in java.util.concurrent with Unsafe.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding a releaseFence() to ConcurrentskipListSet.clone()

I think these changes look good. Before we integrate, could you please raise an issue with the future improvements of `clone()` and friends so that we do not forget that?

-------------

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24821#pullrequestreview-2790715897

From dl at openjdk.org  Thu Apr 24 11:26:46 2025
From: dl at openjdk.org (Doug Lea)
Date: Thu, 24 Apr 2025 11:26:46 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent [v2]
In-Reply-To: <6NDgDTwJ7E3fBSTB-WVtTQLFMkeJwnPo0ex96kpTbag=.1f20daed-f9a0-4e55-b85e-11291c8a7a9d@github.com>
References: 
 
 
 <6NDgDTwJ7E3fBSTB-WVtTQLFMkeJwnPo0ex96kpTbag=.1f20daed-f9a0-4e55-b85e-11291c8a7a9d@github.com>
Message-ID: 

On Wed, 23 Apr 2025 12:38:55 GMT, Alan Bateman  wrote:

>> Yeah, I originally did that, but the following patch is the "smallest change".
>> Given that the "original code" obtained the Field instance each call, this is still likely a performance improvement.
>
> This code has always used getDeclaredField each time so if anyone had run into a performance issue then we should have heard by now. So I think keeping the changes simple and just moving to Unsafe is okay for now.

Fine. The main effect of this change is to nearly revert to the pre-VarHandle version of this code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24821#discussion_r2058157158

From dl at openjdk.org  Thu Apr 24 11:30:41 2025
From: dl at openjdk.org (Doug Lea)
Date: Thu, 24 Apr 2025 11:30:41 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 15:22:37 GMT, Viktor Klang  wrote:

>> This Pull Request replaces the uses of Field + setAccessible to modify final fields in java.util.concurrent with Unsafe.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding a releaseFence() to ConcurrentskipListSet.clone()

Marked as reviewed by dl (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24821#pullrequestreview-2790744154

From dl at openjdk.org  Thu Apr 24 11:30:42 2025
From: dl at openjdk.org (Doug Lea)
Date: Thu, 24 Apr 2025 11:30:42 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent [v2]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <4e9WGwZc4b558gUF9N5D3LIj35GTbREiSVDHT1thOMI=.a1541a51-9c9a-42c1-a67a-e72d1308e9f2@github.com>

On Wed, 23 Apr 2025 17:54:03 GMT, Chen Liang  wrote:

>> I wonder if we could just change it to return `new ConcurrentSkipListSet<>(m)`. COWAL could be changed to return a new object too.
>
> The set only has a map field, and AbstractSet does not define any additional field. The map should be fine too - two fields in AbstractMap are cleared when cloning happens, so recreating a map from a constructor should have the same effect. (Note a significant field `head` is not cleared upon clone, but seems immediately replaced later in `buildFromSorted`). Both should still be fine with this new return values.

As others have mentioned, clone() needs to be re-checked wrt issuing final field fences. But can be conservatively done so here anyway.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24821#discussion_r2058163496

From mli at openjdk.org  Thu Apr 24 11:36:53 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 24 Apr 2025 11:36:53 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v13]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 23:54:01 GMT, Vladimir Ivanov  wrote:

>> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
>> 
>> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
>> 
>> The patch consists of the following parts:
>>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
>> 
>> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
>> 
>> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
>> 
>> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
>> 
>> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
>> 
>> Thanks!
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CPUFeatures: RISC-V support

Marked as reviewed by mli (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24462#pullrequestreview-2790760838

From mli at openjdk.org  Thu Apr 24 11:36:54 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 24 Apr 2025 11:36:54 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v12]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Wed, 23 Apr 2025 23:55:50 GMT, Vladimir Ivanov  wrote:

>> Does the following check catch `UseRVV == false` case on RISC-V? 
>> 
>> public boolean isSupported(Operator op, VectorSpecies vspecies) {
>> ...
>>             int maxLaneCount = VectorSupport.getMaxLaneCount(vspecies.elementType());
>>             if (vspecies.length() > maxLaneCount) {
>>                 return false; // lacking vector support
>>             }
>> ...
>
> FTR both `VectorSupport.getMaxLaneCount()` and `CPUFeatures` don't rely on  raw list of ISA extensions CPU supports, but only those reported by the JVM. So, if some feature support is disabled on JVM side, it won't be reported by `VM_Version` and, hence, `CPUFeatures`.

Thank you for updating! Looks good for riscv. I have ran some basic tests for vector API, passed. I did not ran benchmark, as riscv & aarch64 share the same way to bridge from java to sleef.

> Does the following check catch UseRVV == false case on RISC-V?

Yes. If you don't mind, an explicit comment might be helpful. As to me "lacking vector support" here means the vector length is not large enough, but it's quite subjective, so you are on the call.

> FTR both VectorSupport.getMaxLaneCount() and CPUFeatures don't rely on raw list of ISA extensions CPU supports, but only those reported by the JVM. So, if some feature support is disabled on JVM side, it won't be reported by VM_Version and, hence, CPUFeatures.

I'm fine with this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2058172975

From rgiulietti at openjdk.org  Thu Apr 24 11:47:47 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 24 Apr 2025 11:47:47 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 15:22:37 GMT, Viktor Klang  wrote:

>> This Pull Request replaces the uses of Field + setAccessible to modify final fields in java.util.concurrent with Unsafe.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding a releaseFence() to ConcurrentskipListSet.clone()

LGTM

-------------

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24821#pullrequestreview-2790790850

From pminborg at openjdk.org  Thu Apr 24 11:52:42 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Apr 2025 11:52:42 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v4]
In-Reply-To: 
References: 
Message-ID: 

> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
> 
> 
> Here are some benchmarks that ran on a platform thread and virtual threads respectively (M1 Mac):
> 
> 
> Benchmark                                                  Mode  Cnt   Score   Error  Units
> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.330 ? 0.820  ns/op
> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.257 ? 0.117  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  41.415 ? 1.013  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.720 ? 0.463  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.636 ? 0.182  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.234 ? 0.156  ns/op
> CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.918 ? 0.487  ns/op
> CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   4.946 ? 0.089  ns/op
> CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.280 ? 1.128  ns/op
> CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  21.809 ? 0.413  ns/op
> CaptureStateUtilBench.tlAllocationFail                     avgt   30  24.422 ? 0.673  ns/op
> CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   5.182 ? 0.152  ns/op
> 
> 
> Adapted system call:
> 
>         return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool
> ```        
> Explicit allocation:
> 
>         try (var arena = Arena.ofConfined()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
>         }
> ```        
> Thread Local allocation:
> 
>         try (var arena = POOLS.take()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool
>         }
> ```        
> The adapted system call exhibits a ~4x performance improvement over the existing "explicit allocation" scheme for the happy path on platform threads. ...

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:

 - Merge master
 - Merge master
 - Add test for woven allocation
 - Merge branch 'master' into errno-util3
 - Use lazy initialization of method handles
 - Clean up visibility
 - Merge branch 'master' into errno-util3
 - Add @ForceInline annotations
 - Add out of order test for VTs
 - Allow memory reuse for several arenas
 - ... and 25 more: https://git.openjdk.org/jdk/compare/290d24d1...1a31ae04

-------------

Changes: https://git.openjdk.org/jdk/pull/23765/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23765&range=03
  Stats: 1911 lines in 13 files changed: 1901 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/23765.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23765/head:pull/23765

PR: https://git.openjdk.org/jdk/pull/23765

From pminborg at openjdk.org  Thu Apr 24 12:06:48 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 24 Apr 2025 12:06:48 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v5]
In-Reply-To: 
References: 
Message-ID: <_jWjgy2uoSpcVVHG2pyfok7mzR_JkoT8Bpz0-KNypJg=.e079daf6-b90e-4af2-acc7-d8c692ebf975@github.com>

> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
> 
> 
> Here are some benchmarks that ran on a platform thread and virtual threads respectively (M1 Mac):
> 
> 
> Benchmark                                                  Mode  Cnt   Score   Error  Units
> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.330 ? 0.820  ns/op
> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.257 ? 0.117  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  41.415 ? 1.013  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.720 ? 0.463  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.636 ? 0.182  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.234 ? 0.156  ns/op
> CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.918 ? 0.487  ns/op
> CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   4.946 ? 0.089  ns/op
> CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.280 ? 1.128  ns/op
> CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  21.809 ? 0.413  ns/op
> CaptureStateUtilBench.tlAllocationFail                     avgt   30  24.422 ? 0.673  ns/op
> CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   5.182 ? 0.152  ns/op
> 
> 
> Adapted system call:
> 
>         return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool
> ```        
> Explicit allocation:
> 
>         try (var arena = Arena.ofConfined()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
>         }
> ```        
> Thread Local allocation:
> 
>         try (var arena = POOLS.take()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool
>         }
> ```        
> The adapted system call exhibits a ~4x performance improvement over the existing "explicit allocation" scheme for the happy path on platform threads. ...

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Revert change to ArenaImpl

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23765/files
  - new: https://git.openjdk.org/jdk/pull/23765/files/1a31ae04..c0e46d30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23765&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23765&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23765.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23765/head:pull/23765

PR: https://git.openjdk.org/jdk/pull/23765

From alanb at openjdk.org  Thu Apr 24 12:33:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Apr 2025 12:33:47 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 23 Apr 2025 16:23:00 GMT, Chen Liang  wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding a releaseFence() to ConcurrentskipListSet.clone()
>
> Thanks. We can investigate how clone cleanups interact with truly final or strict finals in another issue.

> @liach @AlanBateman My proposal here would be to move forward with the proposed changes for now, and then once 25 is branched off there's an opportunity to take a broader look at `clone()`.

Okay with me. We can also add a non-public constructor to some of these classes and use it from readResolve so that we don't need readObject methods that mutate finals.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24821#issuecomment-2827444652

From alanb at openjdk.org  Thu Apr 24 12:33:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Apr 2025 12:33:46 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 15:22:37 GMT, Viktor Klang  wrote:

>> This Pull Request replaces the uses of Field + setAccessible to modify final fields in java.util.concurrent with Unsafe.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding a releaseFence() to ConcurrentskipListSet.clone()

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24821#pullrequestreview-2790943049

From vklang at openjdk.org  Thu Apr 24 14:17:19 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 24 Apr 2025 14:17:19 GMT
Subject: Integrated: 8355369: Remove setAccessible usage for setting final
 fields in java.util.concurrent
In-Reply-To: 
References: 
Message-ID: 

On Wed, 23 Apr 2025 10:10:54 GMT, Viktor Klang  wrote:

> This Pull Request replaces the uses of Field + setAccessible to modify final fields in java.util.concurrent with Unsafe.

This pull request has now been integrated.

Changeset: 356c4d9c
Author:    Viktor Klang 
URL:       https://git.openjdk.org/jdk/commit/356c4d9ca93c8a37231e86d583ce9628d693c733
Stats:     32 lines in 3 files changed: 7 ins; 6 del; 19 mod

8355369: Remove setAccessible usage for setting final fields in java.util.concurrent

Reviewed-by: pminborg, dl, rgiulietti, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/24821

From vklang at openjdk.org  Thu Apr 24 14:17:17 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 24 Apr 2025 14:17:17 GMT
Subject: RFR: 8355369: Remove setAccessible usage for setting final fields
 in java.util.concurrent [v2]
In-Reply-To: <4e9WGwZc4b558gUF9N5D3LIj35GTbREiSVDHT1thOMI=.a1541a51-9c9a-42c1-a67a-e72d1308e9f2@github.com>
References: 
 
 
 
 
 <4e9WGwZc4b558gUF9N5D3LIj35GTbREiSVDHT1thOMI=.a1541a51-9c9a-42c1-a67a-e72d1308e9f2@github.com>
Message-ID: 

On Thu, 24 Apr 2025 11:27:32 GMT, Doug Lea 
 wrote:

>> The set only has a map field, and AbstractSet does not define any additional field. The map should be fine too - two fields in AbstractMap are cleared when cloning happens, so recreating a map from a constructor should have the same effect. (Note a significant field `head` is not cleared upon clone, but seems immediately replaced later in `buildFromSorted`). Both should still be fine with this new return values.
>
> As others have mentioned, clone() needs to be re-checked wrt issuing final field fences. But can be conservatively done so here anyway.

@DougLea Yeah. I'd be surprised if `clone()`-invocations were specially tracked to get a trailing release fence inserted before handing out the instance.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24821#discussion_r2058547956

From duke at openjdk.org  Thu Apr 24 15:03:50 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 24 Apr 2025 15:03:50 GMT
Subject: RFR: 8077587: BigInteger Roots [v30]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Some optimizations

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/8676af7c..3cf820b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=28-29

  Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From jiangli at openjdk.org  Thu Apr 24 15:07:52 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 24 Apr 2025 15:07:52 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Apr 2025 21:32:48 GMT, Chen Liang  wrote:

>> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
>>  - Address henryjen@ comment:
>>    - Remove '#include '.
>
> `sysLookup` does look much cleaner compared to `jdkLibraryPath`.

@liach @slowhog Can you approve the change? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2827970628

From duke at openjdk.org  Thu Apr 24 15:14:42 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 24 Apr 2025 15:14:42 GMT
Subject: RFR: 8077587: BigInteger Roots [v31]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.
> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Systematization of special cases in BigInteger.pow(int)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/3cf820b2..23914e8a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=29-30

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From henryjen at openjdk.org  Thu Apr 24 15:16:54 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 24 Apr 2025 15:16:54 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
References: 
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
Message-ID: 

On Wed, 23 Apr 2025 00:56:18 GMT, Jiangli Zhou  wrote:

>> Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
>> 
>> `NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.
>> 
>> In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
>  - Address henryjen@ comment:
>    - Remove '#include '.

src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java line 135:

> 133:     @SuppressWarnings("restricted")
> 134:     private static SymbolLookup sysLookup() {
> 135:         NativeLibraries libs = NativeLibraries.newInstance(null);

I would have @mcimadamore or @JornVernee look at this for the native function call permission requirements.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24801#discussion_r2058685087

From liach at openjdk.org  Thu Apr 24 15:57:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Apr 2025 15:57:59 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 Mar 2025 15:21:33 GMT, Per Minborg  wrote:

>> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
>> 
>> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
>> 
>> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
>> 
>> 
>> Here are some benchmarks that ran on a platform thread and virtual threads respectively (M1 Mac):
>> 
>> 
>> Benchmark                                                  Mode  Cnt   Score   Error  Units
>> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.330 ? 0.820  ns/op
>> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.257 ? 0.117  ns/op
>> CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  41.415 ? 1.013  ns/op
>> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.720 ? 0.463  ns/op
>> CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.636 ? 0.182  ns/op
>> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.234 ? 0.156  ns/op
>> CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.918 ? 0.487  ns/op
>> CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   4.946 ? 0.089  ns/op
>> CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.280 ? 1.128  ns/op
>> CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  21.809 ? 0.413  ns/op
>> CaptureStateUtilBench.tlAllocationFail                     avgt   30  24.422 ? 0.673  ns/op
>> CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   5.182 ? 0.152  ns/op
>> 
>> 
>> Adapted system call:
>> 
>>         return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool
>> ```        
>> Explicit allocation:
>> 
>>         try (var arena = Arena.ofConfined()) {
>>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
>>         }
>> ```        
>> Thread Local allocation:
>> 
>>         try (var arena = POOLS.take()) {
>>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool
>>         }
>> ```        
>> The adapted system call exhibits a ~4x performance improvement ove...
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
> 
>  - Merge master
>  - Add test for woven allocation
>  - Merge branch 'master' into errno-util3
>  - Use lazy initialization of method handles
>  - Clean up visibility
>  - Merge branch 'master' into errno-util3
>  - Add @ForceInline annotations
>  - Add out of order test for VTs
>  - Allow memory reuse for several arenas
>  - Remove file
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/4e51a8c9...6d782a84

src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 65:

> 63:     //   returnType in {int.class | long.class}
> 64:     //   stateName can be anything non-null but should be in {"GetLastError" | "WSAGetLastError"} | "errno")}
> 65:     private record BasicKey(Class returnType, String stateName) {

Please at least add an `hashCode` - this avoids a hefty overhead from code generation in ObjectMethods.bootstrap, unavoidable whenever we put entries into a hash map.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23765#discussion_r2056408940

From iklam at openjdk.org  Thu Apr 24 16:10:11 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 24 Apr 2025 16:10:11 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache
Message-ID: 

This PR contains 2 parts

- Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
- New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.

One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):

- When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
- When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 

`ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:

- If an entry has not yet been collected, we make sure it will never be collected.
- If an entry has been collected, we remove it from the table

Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.

This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.

In the future, we may relax the implementation to allow for other use cases.

-------------

Commit messages:
 - Merge branch 'master' into 8354897-soft-weak-references-in-aot-cache
 - cleaned up test cases
 - Added missing files
 - Avoid the need to Universe::reference_pending_list() and remove assumptions on GC behavior. Suggested by @fisk
 - Added code to process Universe::reference_pending_list()
 - 8354897: Support Soft/Weak Reference in AOT cache (imported from Leyden repo)

Changes: https://git.openjdk.org/jdk/pull/24757/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24757&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354897
  Stats: 784 lines in 21 files changed: 627 ins; 102 del; 55 mod
  Patch: https://git.openjdk.org/jdk/pull/24757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24757/head:pull/24757

PR: https://git.openjdk.org/jdk/pull/24757

From smarks at openjdk.org  Thu Apr 24 16:27:53 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 24 Apr 2025 16:27:53 GMT
Subject: RFR: 8354424: java/util/logging/LoggingDeadlock5.java fails
 intermittently in tier6 [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 22 Apr 2025 13:53:14 GMT, Daniel Fuchs  wrote:

>> test/jdk/java/util/logging/LoggingDeadlock5.java line 127:
>> 
>>> 125:         // in higher tiers, so it's necessary to be a bit pessimistic here.
>>> 126:         private final static Duration JOIN_WAIT =
>>> 127:                 Duration.ofMillis(Utils.adjustTimeout(2000));
>> 
>> Just checking, adjustTimeout does scaling based on the timeout factor given to jtreg?
>> 
>> What happens to the expected test running time to the test in lower tiers without as high loads?
>
> Hi Joe, yes `adjustTimeout` will scale based on the jtreg timeout factor. I believe the behaviour is to multiply whatever hardcoded timeout is passed by the timeout factor.
> On lower tiers, in our CI, I beleive it means the test will have to wait for 8s before it can assert that a deadlock is detected. That should be way off the default jtreg timeout - which IIRC is 480s on lower tiers.

Note, the timeout factor also adjusts the jtreg timeout for the entire test. The adjustTimeout() method allows internal test timeouts to scale along with the jtreg timeout.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24687#discussion_r2058825862

From smarks at openjdk.org  Thu Apr 24 16:30:42 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 24 Apr 2025 16:30:42 GMT
Subject: RFR: 8354424: java/util/logging/LoggingDeadlock5.java fails
 intermittently in tier6 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 16 Apr 2025 17:37:07 GMT, David Beaumont  wrote:

>> Increasing timeout for deadlock detection and adjusting for the timeout factor in higher tiers.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing test from the problem list.

Looks reasonable. This raises the base timeout by 4x. It also includes the timeout factor adjustment, which can be quite large (8x?) in higher tiers. I think at this point we just have to expose it to more runs to see whether it still fails too frequently.

-------------

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24687#pullrequestreview-2791829277

From smarks at openjdk.org  Thu Apr 24 16:31:47 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 24 Apr 2025 16:31:47 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 22 Apr 2025 18:56:40 GMT, Stuart Marks  wrote:

>> src/java.base/share/classes/java/lang/IO.java line 41:
>> 
>>> 39:  * The {@link #readln()} and {@link #readln(String)} methods decode bytes read from
>>> 40:  * {@code System.in} into characters. The charset used for decoding is specified by the
>>> 41:  * {@link System#getProperties stdin.encoding} property. If this property is not present,
>> 
>> @stuart-marks Are you planning to propose/integrate pull/24738 in advance of the JEP update? Asking because this paragraph will need to be adjusted if pull/24738 doesn't go in first.
>
> Depends on how close you think 24738 is to being ready. As it stands it seems ok; but I'm still looking at the potential impact on other part of the JDK. In particular are there other JDK APIs that should be adjusted to mention `stdin.encoding`?
> 
> As for the impact here, if 24738 doesn't go in first, then I'm not quite sure what this should say. I guess it could say "default charset" or something and then it could be amended with a bugfix later.

(After some further discussion, it looks like 24738 is quite close to being ready.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2058832242

From naoto at openjdk.org  Thu Apr 24 16:32:41 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 24 Apr 2025 16:32:41 GMT
Subject: RFR: 8350703: Add standard system property stdin.encoding [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 18:02:56 GMT, Stuart Marks  wrote:

>> * Windows and Unix: set sprops.stdin_encoding if connected to a console
>> * Add specs for stdin.encoding
>> * Adjust specs to change "undefined" to "unspecified"
>> * Rewrite System.in spec to refer to new property and to clarify usage with classes that perform encoding
>> * Update property test
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Yet another minor bit of wordsmithing.

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24738#pullrequestreview-2791835320

From dfuchs at openjdk.org  Thu Apr 24 16:34:48 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 24 Apr 2025 16:34:48 GMT
Subject: RFR: 8354424: java/util/logging/LoggingDeadlock5.java fails
 intermittently in tier6 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 16 Apr 2025 17:37:07 GMT, David Beaumont  wrote:

>> Increasing timeout for deadlock detection and adjusting for the timeout factor in higher tiers.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing test from the problem list.

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24687#pullrequestreview-2791839194

From michaelm at openjdk.org  Thu Apr 24 16:43:43 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 24 Apr 2025 16:43:43 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v7]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  Review update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/da33863c..efabc485

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=05-06

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From naoto at openjdk.org  Thu Apr 24 16:44:45 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 24 Apr 2025 16:44:45 GMT
Subject: RFR: 8355443: [java.io] Use @requires tag instead of exiting based
 on File.separatorChar value
In-Reply-To: 
References: 
Message-ID: 

On Thu, 24 Apr 2025 00:33:20 GMT, Brian Burkhalter  wrote:

> For tests of the `java.io` package, instead of doing this
> 
>     public static void main(String[] args) throws Exception {
>         if (File.separatorChar != '\') {
>             /* This test is only valid on win32 systems */
>             return;
>         }
> 
> do this
> 
>    @requires (os.family == "windows")

Nice cleanup.

test/jdk/java/io/pathNames/win32/SJIS.java line 51:

> 49:            that use the SJIS encoding */
> 50:         String enc = System.getProperty("file.encoding");
> 51:         if ((enc == null) || !enc.equals("SJIS")) return;

I just wonder this test has ever run since JDK18, as file.encoding is always UTF-8 unless COMPAT is specified (and this test case does not specify it)

-------------

PR Review: https://git.openjdk.org/jdk/pull/24838#pullrequestreview-2791863041
PR Review Comment: https://git.openjdk.org/jdk/pull/24838#discussion_r2058850665

From bpb at openjdk.org  Thu Apr 24 16:57:50 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 24 Apr 2025 16:57:50 GMT
Subject: RFR: 8355443: [java.io] Use @requires tag instead of exiting based
 on File.separatorChar value
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 24 Apr 2025 16:41:27 GMT, Naoto Sato  wrote:

>> For tests of the `java.io` package, instead of doing this
>> 
>>     public static void main(String[] args) throws Exception {
>>         if (File.separatorChar != '\') {
>>             /* This test is only valid on win32 systems */
>>             return;
>>         }
>> 
>> do this
>> 
>>    @requires (os.family == "windows")
>
> test/jdk/java/io/pathNames/win32/SJIS.java line 51:
> 
>> 49:            that use the SJIS encoding */
>> 50:         String enc = System.getProperty("file.encoding");
>> 51:         if ((enc == null) || !enc.equals("SJIS")) return;
> 
> I just wonder this test has ever run since JDK18, as file.encoding is always UTF-8 unless COMPAT is specified (and this test case does not specify it)

So do you think that this test should be removed? If so, I think that would be a different PR. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24838#discussion_r2058870526

From dfuchs at openjdk.org  Thu Apr 24 16:59:45 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 24 Apr 2025 16:59:45 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: 
References: 
Message-ID: <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement 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 409 commits:

 - merge latest changes from master branch
 - http3: add missing 
 separator to Http3DiscoveryMode.ALT_SVC API documentation
 - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
 - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
 - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
 - http3: minor improvement to log message
 - http3: Artur's review - remove commented out code from test
 - http3: Artur's review - make methods package private
 - http3: qpack - allow 0 capacity when max capacity is 0
 - Remove flow control from stream limit comments
 - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe

-------------

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=01
  Stats: 102765 lines in 470 files changed: 100142 ins; 1119 del; 1504 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 naoto at openjdk.org  Thu Apr 24 17:09:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 24 Apr 2025 17:09:50 GMT
Subject: RFR: 8355443: [java.io] Use @requires tag instead of exiting based
 on File.separatorChar value
In-Reply-To: 
References: 
 
 
Message-ID: <99snxMdIvwClX8j8gTmDfqo_RTgioRwN-lU346U2UJo=.bd60f9b1-dff2-468d-b17d-5ef454b69c9c@github.com>

On Thu, 24 Apr 2025 16:55:16 GMT, Brian Burkhalter  wrote:

>> test/jdk/java/io/pathNames/win32/SJIS.java line 51:
>> 
>>> 49:            that use the SJIS encoding */
>>> 50:         String enc = System.getProperty("file.encoding");
>>> 51:         if ((enc == null) || !enc.equals("SJIS")) return;
>> 
>> I just wonder this test has ever run since JDK18, as file.encoding is always UTF-8 unless COMPAT is specified (and this test case does not specify it)
>
> So do you think that this test should be removed? If so, I think that would be a different PR. Thanks.

IIUC, the test tries to create double byte path directory, so in recent jdk it should check `sun.jnu.encoding==MS932` (it still only run on Japanese Windows though)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24838#discussion_r2058888444

From naoto at openjdk.org  Thu Apr 24 17:24:45 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 24 Apr 2025 17:24:45 GMT
Subject: RFR: 8355443: [java.io] Use @requires tag instead of exiting based
 on File.separatorChar value
In-Reply-To: 
References: 
Message-ID: 

On Thu, 24 Apr 2025 00:33:20 GMT, Brian Burkhalter  wrote:

> For tests of the `java.io` package, instead of doing this
> 
>     public static void main(String[] args) throws Exception {
>         if (File.separatorChar != '\') {
>             /* This test is only valid on win32 systems */
>             return;
>         }
> 
> do this
> 
>    @requires (os.family == "windows")

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24838#pullrequestreview-2791975852

From bpb at openjdk.org  Thu Apr 24 17:24:46 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 24 Apr 2025 17:24:46 GMT
Subject: RFR: 8355443: [java.io] Use @requires tag instead of exiting based
 on File.separatorChar value
In-Reply-To: <99snxMdIvwClX8j8gTmDfqo_RTgioRwN-lU346U2UJo=.bd60f9b1-dff2-468d-b17d-5ef454b69c9c@github.com>
References: 
 
 
 <99snxMdIvwClX8j8gTmDfqo_RTgioRwN-lU346U2UJo=.bd60f9b1-dff2-468d-b17d-5ef454b69c9c@github.com>
Message-ID: <1asenKPdexHlF3nn-pOdwRF-yfUk3BbaRTNrIZHwNuI=.56e09305-d3e6-4481-b72a-5702aae5099a@github.com>

On Thu, 24 Apr 2025 17:07:15 GMT, Naoto Sato  wrote:

>> So do you think that this test should be removed? If so, I think that would be a different PR. Thanks.
>
> IIUC, the test tries to create double byte path directory, so in recent jdk it should check `sun.jnu.encoding==MS932` (it still only run on Japanese Windows though)

Sounds like a different issue needs to be filed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24838#discussion_r2058912342

From naoto at openjdk.org  Thu Apr 24 17:24:46 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 24 Apr 2025 17:24:46 GMT
Subject: RFR: 8355443: [java.io] Use @requires tag instead of exiting based
 on File.separatorChar value
In-Reply-To: <1asenKPdexHlF3nn-pOdwRF-yfUk3BbaRTNrIZHwNuI=.56e09305-d3e6-4481-b72a-5702aae5099a@github.com>
References: 
 
 
 <99snxMdIvwClX8j8gTmDfqo_RTgioRwN-lU346U2UJo=.bd60f9b1-dff2-468d-b17d-5ef454b69c9c@github.com>
 <1asenKPdexHlF3nn-pOdwRF-yfUk3BbaRTNrIZHwNuI=.56e09305-d3e6-4481-b72a-5702aae5099a@github.com>
Message-ID: 

On Thu, 24 Apr 2025 17:20:01 GMT, Brian Burkhalter  wrote:

>> IIUC, the test tries to create double byte path directory, so in recent jdk it should check `sun.jnu.encoding==MS932` (it still only run on Japanese Windows though)
>
> Sounds like a different issue needs to be filed.

Yeah, that sounds better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24838#discussion_r2058915500

From swen at openjdk.org  Thu Apr 24 17:36:29 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 24 Apr 2025 17:36:29 GMT
Subject: RFR: 8355301: Simplify Throwable::printStackTrace by replacing
 inner class with static method [v5]
In-Reply-To: 
References: 
Message-ID: <07nJuCtiCHpwz95wfQKqTC8fXuqB-8hn-wEtESimz2c=.d18e8d12-0155-46ee-a7c5-eb40ae1bb460@github.com>

> The current Throwable::printStackTrace implementation uses three inner classes PrintStreamOrWriter/WrappedPrintStream/WrappedPrintWriter. We can introduce a static method println to replace these three embedded classes.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  use interface + record

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24795/files
  - new: https://git.openjdk.org/jdk/pull/24795/files/b9050803..fd70d1ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24795&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24795&range=03-04

  Stats: 61 lines in 1 file changed: 32 ins; 13 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/24795.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24795/head:pull/24795

PR: https://git.openjdk.org/jdk/pull/24795

From liach at openjdk.org  Thu Apr 24 17:38:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Apr 2025 17:38:58 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <25tnSBnETNb-3aQ_iMam3rpQhBIE08B3042wfpNlAWo=.14fa57d1-e03b-46e5-80a5-c8b747db1826@github.com>
References: 
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
 
 <25tnSBnETNb-3aQ_iMam3rpQhBIE08B3042wfpNlAWo=.14fa57d1-e03b-46e5-80a5-c8b747db1826@github.com>
Message-ID: 

On Thu, 24 Apr 2025 17:33:19 GMT, Jiangli Zhou  wrote:

>> src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java line 135:
>> 
>>> 133:     @SuppressWarnings("restricted")
>>> 134:     private static SymbolLookup sysLookup() {
>>> 135:         NativeLibraries libs = NativeLibraries.newInstance(null);
>> 
>> I would consult @mcimadamore or @JornVernee look at this for the native function call permission requirements.
>
> @mcimadamore or @JornVernee Can you help take a look of this? Thanks!

Unfortunately, I believe both of them are on vacation, yet they have the required expertise to review this PR. You might need to wait a bit, sorry!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24801#discussion_r2058934598

From jiangli at openjdk.org  Thu Apr 24 17:38:57 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 24 Apr 2025 17:38:57 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: 
References: 
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
 
Message-ID: <25tnSBnETNb-3aQ_iMam3rpQhBIE08B3042wfpNlAWo=.14fa57d1-e03b-46e5-80a5-c8b747db1826@github.com>

On Thu, 24 Apr 2025 15:14:27 GMT, Henry Jen  wrote:

>> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
>>  - Address henryjen@ comment:
>>    - Remove '#include '.
>
> src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java line 135:
> 
>> 133:     @SuppressWarnings("restricted")
>> 134:     private static SymbolLookup sysLookup() {
>> 135:         NativeLibraries libs = NativeLibraries.newInstance(null);
> 
> I would consult @mcimadamore or @JornVernee look at this for the native function call permission requirements.

@mcimadamore or @JornVernee Can you help take a look of this? Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24801#discussion_r2058930806

From sgehwolf at openjdk.org  Thu Apr 24 17:39:35 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 24 Apr 2025 17:39:35 GMT
Subject: RFR: 8355524: Only every second line in upgradeable files is being
 used
Message-ID: 

Please review this fix to [JDK-8353185](https://bugs.openjdk.org/browse/JDK-8353185). The reading logic for the config file would erroneously use `scanner.nextLine()` when the current line to be added is in `line`. `line` is not being added, but `scanner.nextLine()` unintentionally skipping lines. The config file has a change too. It moves the `tzdb.dat` line last so that the existing test verifies that the `cacerts` one isn't being skipped. This slipped through because `tzdb.dat` updates aren't automatically tested.

Testing:
- [ ] GHA
- [x] The test from [JDK-8353185](https://bugs.openjdk.org/browse/JDK-8353185), `UpgradeableFileCacertsTest.java` fails with the config file change only (without the product fix) and passes with the one-liner. Also some manual testing when both files have been upgraded.

Thoughts?

-------------

Commit messages:
 - 8355524: Only every second line in upgradable files is being read

Changes: https://git.openjdk.org/jdk/pull/24855/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24855&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355524
  Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24855.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24855/head:pull/24855

PR: https://git.openjdk.org/jdk/pull/24855

From rgiulietti at openjdk.org  Thu Apr 24 18:27:43 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 24 Apr 2025 18:27:43 GMT
Subject: RFR: 8077587: BigInteger Roots [v19]
In-Reply-To: 
References: 
 
 
 
Message-ID: <8Cd065O2M59QfLt9yaOtn61ZEfB3V-oy1ppTn1Ho-pQ=.6d9ee1ab-bdf4-4619-aacf-68d7927635fd@github.com>

On Mon, 21 Apr 2025 11:47:30 GMT, fabioromano1  wrote:

>>> [Here is a proof of convergence of the recurrence used.](https://github.com/user-attachments/files/19785045/nth_root_newton_proof_integers.pdf)
>> 
>> That's very nice. It would be even nicer if this was a permalink into the JDK repo, and a reference in the source code.
>
>> That's very nice. It would be even nicer if this was a permalink into the JDK repo, and a reference in the source code.
> 
> @theRealAph Ok. It would be useful to have a link to an explanation on how this can be done, if there is one. Thanks.

@fabioromano1 I just had a cursory glance at this PR.

AFAIU, there are two main contributions here:

- Performance enhancements in `pow()`, which is of general interest and does not require submitting a [CSR](https://wiki.openjdk.org/display/csr/Main).
- Introduction of a new public API point for the _n_-th root, which would require a CSR.

It's important to understand that if we add public API points, there must be some evidence and consensus about their general usefulness and demand for them. Every addition is a commitment for this community in terms of code maintenance, reviews, testing, documentation, so they should be evaluated with this perspective in mind.

In this case, I feel that the proposed _n_-th root might not be among the top priority API points to add to `BigInteger`. Perhaps the overall plan is to use this method to implement a _n_-th root in `BigDecimal` in some followup PR, but this is not stated here.

Anyway, a [preliminary discussion](https://openjdk.org/guide/#socialize-your-change) about the proposal should take place on the mailing list, _before_ submitting the PR and invest too much work on the code.

To make progress here, I suggest to split this PR in two, if technically possible:

- One for the enhancements in `pow`, with JMH results before/after.
- Another PR for the proposed _n_-th root.

Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2828501417

From shade at openjdk.org  Thu Apr 24 18:40:50 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 24 Apr 2025 18:40:50 GMT
Subject: RFR: 8355524: Only every second line in upgradeable files is being
 used
In-Reply-To: 
References: 
Message-ID: 

On Thu, 24 Apr 2025 17:31:50 GMT, Severin Gehwolf  wrote:

> Please review this fix to [JDK-8353185](https://bugs.openjdk.org/browse/JDK-8353185). The reading logic for the config file would erroneously use `scanner.nextLine()` when the current line to be added is in `line`. `line` is not being added, but `scanner.nextLine()` unintentionally skipping lines. The config file has a change too. It moves the `tzdb.dat` line last so that the existing test verifies that the `cacerts` one isn't being skipped. This slipped through because `tzdb.dat` updates aren't automatically tested.
> 
> Testing:
> - [ ] GHA
> - [x] The test from [JDK-8353185](https://bugs.openjdk.org/browse/JDK-8353185), `UpgradeableFileCacertsTest.java` fails with the config file change only (without the product fix) and passes with the one-liner. Also some manual testing when both files have been upgraded.
> 
> Thoughts?

Ha! The bugfixes like these should be reserved for Friday evenings :)

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24855#pullrequestreview-2792170097

From jbhateja at openjdk.org  Thu Apr 24 18:59:53 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 24 Apr 2025 18:59:53 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v13]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 23:54:01 GMT, Vladimir Ivanov  wrote:

>> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
>> 
>> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
>> 
>> The patch consists of the following parts:
>>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
>> 
>> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
>> 
>> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
>> 
>> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
>> 
>> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
>> 
>> Thanks!
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CPUFeatures: RISC-V support

src/hotspot/share/opto/vectorIntrinsics.cpp line 563:

> 561:     debug_name = debug_name_oop->const_oop()->as_instance()->java_lang_String_str(buf, buflen);
> 562:   }
> 563:   Node* vcall = make_runtime_call(RC_VECTOR,

By generating an upfront CallLeafVectorNode, we may miss out on performing any GVN-style optimization for trigonometric identities like the following. do you think creating a macro node which can lazily be expanded to call node during macro expansion will help.

arcsin(sin(x)) => x
arccos(cos(x)) => x
sin(arcsin(x) => x
cos(arccos(x) => x

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2059057257

From duke at openjdk.org  Thu Apr 24 19:20:56 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 24 Apr 2025 19:20:56 GMT
Subject: Integrated: 8354424: java/util/logging/LoggingDeadlock5.java fails
 intermittently in tier6
In-Reply-To: 
References: 
Message-ID: 

On Wed, 16 Apr 2025 12:12:14 GMT, David Beaumont  wrote:

> Increasing timeout for deadlock detection and adjusting for the timeout factor in higher tiers.

This pull request has now been integrated.

Changeset: e01e33d1
Author:    David Beaumont 
Committer: Daniel Fuchs 
URL:       https://git.openjdk.org/jdk/commit/e01e33d19b94ee85f7cb7cd6baec857a50086c76
Stats:     11 lines in 2 files changed: 9 ins; 1 del; 1 mod

8354424: java/util/logging/LoggingDeadlock5.java fails intermittently in tier6

Reviewed-by: dfuchs, smarks

-------------

PR: https://git.openjdk.org/jdk/pull/24687

From liach at openjdk.org  Thu Apr 24 19:54:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Apr 2025 19:54:46 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Apr 2025 18:31:05 GMT, Ioi Lam  wrote:

> This PR contains 2 parts
> 
> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.
> 
> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):
> 
> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 
> 
> `ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:
> 
> - If an entry has not yet been collected, we make sure it will never be collected.
> - If an entry has been collected, we remove it from the table
> 
> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.
> 
> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.
> 
> In the future, we may relax the implementation to allow for other use cases.

src/java.base/share/classes/jdk/internal/util/ReferencedKeyMap.java line 355:

> 353:             if (referent == null) {
> 354:                 // We don't need this key anymore. Add to stale queue
> 355:                 ((Reference)key).enqueue();

Is enqueue necessary here? Afaik this map only uses the queue to be alert of member reference being garbage collected and then remove stale elements. Since at this stage this map is no longer used, maybe `key.unused()` is sufficient?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2059128012

From duke at openjdk.org  Thu Apr 24 20:21:52 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 24 Apr 2025 20:21:52 GMT
Subject: RFR: 8077587: BigInteger Roots [v19]
In-Reply-To: <8Cd065O2M59QfLt9yaOtn61ZEfB3V-oy1ppTn1Ho-pQ=.6d9ee1ab-bdf4-4619-aacf-68d7927635fd@github.com>
References: 
 
 
 
 <8Cd065O2M59QfLt9yaOtn61ZEfB3V-oy1ppTn1Ho-pQ=.6d9ee1ab-bdf4-4619-aacf-68d7927635fd@github.com>
Message-ID: 

On Thu, 24 Apr 2025 18:17:38 GMT, Raffaello Giulietti  wrote:

> * Performance enhancements in `pow()`, which is of general interest and does not require submitting a [CSR](https://wiki.openjdk.org/display/csr/Main).

@rgiulietti Yes, but here, the primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

> To make progress here, I suggest to split this PR in two, if technically possible:
> 
> * One for the enhancements in `pow`, with JMH results before/after.
> * Another PR for the proposed _n_-th root.

I'm not very sure if it is technically possible, because both `pow()` and `nthRoot()` requires the computation of a power of a long, so that code has to be shared by both methods, and so a supposed PR for `nthRoot()` would require that method.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2828760458

From bpb at openjdk.org  Thu Apr 24 20:52:56 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 24 Apr 2025 20:52:56 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based on
 os.name property value
Message-ID: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>

Use the `@requires` tag instead of obtaining the operating system name from the `os.name` property and then exiting if the test is not run on that operating system.

-------------

Commit messages:
 - 8355444: [java.io] Use @requires tag instead of exiting based on os.name property value

Changes: https://git.openjdk.org/jdk/pull/24860/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24860&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355444
  Stats: 36 lines in 6 files changed: 11 ins; 19 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24860/head:pull/24860

PR: https://git.openjdk.org/jdk/pull/24860

From lancea at openjdk.org  Thu Apr 24 20:59:48 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 24 Apr 2025 20:59:48 GMT
Subject: RFR: [java.io] Use @requires tag instead of exiting based on
 "os.name" property value
In-Reply-To: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
Message-ID: 

On Thu, 24 Apr 2025 20:46:42 GMT, Brian Burkhalter  wrote:

> Use the `@requires` tag instead of obtaining the operating system name from the `os.name` property and then exiting if the test is not run on that operating system.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24860#pullrequestreview-2792485973

From eosterlund at openjdk.org  Thu Apr 24 21:03:52 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 24 Apr 2025 21:03:52 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache
In-Reply-To: 
References: 
 
Message-ID: <-GF25_Ii00bRTXBlGtgeZHhHlhemUokpbzhe3mZnUgc=.ba7064e9-68a1-435d-89f5-73576fad0b4e@github.com>

On Thu, 24 Apr 2025 19:52:25 GMT, Chen Liang  wrote:

>> This PR contains 2 parts
>> 
>> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
>> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.
>> 
>> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):
>> 
>> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
>> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 
>> 
>> `ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:
>> 
>> - If an entry has not yet been collected, we make sure it will never be collected.
>> - If an entry has been collected, we remove it from the table
>> 
>> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.
>> 
>> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.
>> 
>> In the future, we may relax the implementation to allow for other use cases.
>
> src/java.base/share/classes/jdk/internal/util/ReferencedKeyMap.java line 355:
> 
>> 353:             if (referent == null) {
>> 354:                 // We don't need this key anymore. Add to stale queue
>> 355:                 ((Reference)key).enqueue();
> 
> Is enqueue necessary here? Afaik this map only uses the queue to be alert of member reference being garbage collected and then remove stale elements. Since at this stage this map is no longer used, maybe `key.unused()` is sufficient?

I'm not sure what you are proposing. But enqueue is used to ensure that inactive references are pruned from the data structure so that dumping only includes active references. This way, the JVM that loads these objects create these references as active and hence follow the usual life cycle that every other reference does. I want to avoid having a new "special" life cycles for dumped references.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2059226257

From iklam at openjdk.org  Thu Apr 24 21:13:49 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 24 Apr 2025 21:13:49 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache
In-Reply-To: <-GF25_Ii00bRTXBlGtgeZHhHlhemUokpbzhe3mZnUgc=.ba7064e9-68a1-435d-89f5-73576fad0b4e@github.com>
References: 
 
 <-GF25_Ii00bRTXBlGtgeZHhHlhemUokpbzhe3mZnUgc=.ba7064e9-68a1-435d-89f5-73576fad0b4e@github.com>
Message-ID: 

On Thu, 24 Apr 2025 21:01:11 GMT, Erik ?sterlund  wrote:

>> src/java.base/share/classes/jdk/internal/util/ReferencedKeyMap.java line 355:
>> 
>>> 353:             if (referent == null) {
>>> 354:                 // We don't need this key anymore. Add to stale queue
>>> 355:                 ((Reference)key).enqueue();
>> 
>> Is enqueue necessary here? Afaik this map only uses the queue to be alert of member reference being garbage collected and then remove stale elements. Since at this stage this map is no longer used, maybe `key.unused()` is sufficient?
>
> I'm not sure what you are proposing. But enqueue is used to ensure that inactive references are pruned from the data structure so that dumping only includes active references. This way, the JVM that loads these objects create these references as active and hence follow the usual life cycle that every other reference does. I want to avoid having a new "special" life cycles for dumped references.

The map is still being used (and will be stored into the AOT cache). The key no longer has a referent, so we need to remove the key from the map. Adding the key to the stale queue and calling `removeStaleReferences()` will accomplish this. `key.unused()` does not remove the key from the map.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2059235560

From liach at openjdk.org  Thu Apr 24 21:13:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Apr 2025 21:13:49 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache
In-Reply-To: 
References: 
 
 <-GF25_Ii00bRTXBlGtgeZHhHlhemUokpbzhe3mZnUgc=.ba7064e9-68a1-435d-89f5-73576fad0b4e@github.com>
 
Message-ID: 

On Thu, 24 Apr 2025 21:09:10 GMT, Ioi Lam  wrote:

>> I'm not sure what you are proposing. But enqueue is used to ensure that inactive references are pruned from the data structure so that dumping only includes active references. This way, the JVM that loads these objects create these references as active and hence follow the usual life cycle that every other reference does. I want to avoid having a new "special" life cycles for dumped references.
>
> The map is still being used (and will be stored into the AOT cache). The key no longer has a referent, so we need to remove the key from the map. Adding the key to the stale queue and calling `removeStaleReferences()` will accomplish this. `key.unused()` does not remove the key from the map.

Thanks. I am fine with the rest of the core library changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2059237363

From eosterlund at openjdk.org  Thu Apr 24 22:25:51 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 24 Apr 2025 22:25:51 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Apr 2025 18:31:05 GMT, Ioi Lam  wrote:

> This PR contains 2 parts
> 
> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.
> 
> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):
> 
> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 
> 
> `ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:
> 
> - If an entry has not yet been collected, we make sure it will never be collected.
> - If an entry has been collected, we remove it from the table
> 
> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.
> 
> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.
> 
> In the future, we may relax the implementation to allow for other use cases.

Changes requested by eosterlund (Reviewer).

src/hotspot/share/cds/heapShared.cpp line 1408:

> 1406:     oop obj = RawAccess<>::oop_load(p);
> 1407:     if (!CompressedOops::is_null(obj)) {
> 1408:       int field_offset = pointer_delta_as_int((char*)p, cast_from_oop(_referencing_obj));

The RawAccess oop load above should probably be a HeapAccess::oop_load_at. By using the unknown oop ref and supplying the field offset, we allow GCs to infer the actual reference strength in the backend when loading and apply appropriate barriers for non-strong references, while also applying appropriate load barriers for conc GCs.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24757#pullrequestreview-2792646427
PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2059322068

From liach at openjdk.org  Thu Apr 24 22:46:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Apr 2025 22:46:01 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v6]
In-Reply-To: 
References: 
Message-ID: 

> Some AccessFlag parsing methods throw IAE because a flag mask is not valid in a location. However, there is no easy way to check what flag mask bits or what flags are valid for a location. We need such APIs to check, specific to each class file format version.
> 
> Also in the investigation, it's noted that `ACC_SYNTHETIC` is incorrectly represented - it is available since release 5.0 instead of release 7. This bug is fixed together for implementation simplicity.
> 
> The new methods are all in `AccessFlag.Location`:
> - `Set flags()`
> - `int flagsMask()`
> - `Set flags(ClassFileFormatVersion)`
> - `int flagsMask(ClassFileFormatVersion)`
> 
> Also there is some simplification to `AccessFlag` itself to remove the anonymous classes, which should be more startup-friendly.
> 
> Testing: Tier 1-3

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 eight additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-location-accessors
 - Preview notes
 - Further enhance the impl of access flags, make cffv aware to flags easier
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-location-accessors
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-location-accessors
 - More links
 - ClassLoading order, Typos in NPE test
 - 8347471: Provide valid flags and mask in AccessFlag.Location

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23095/files
  - new: https://git.openjdk.org/jdk/pull/23095/files/7e6d58a1..1019812f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23095&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23095&range=04-05

  Stats: 35133 lines in 1000 files changed: 27235 ins; 5788 del; 2110 mod
  Patch: https://git.openjdk.org/jdk/pull/23095.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23095/head:pull/23095

PR: https://git.openjdk.org/jdk/pull/23095

From vlivanov at openjdk.org  Thu Apr 24 23:06:50 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 24 Apr 2025 23:06:50 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v13]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 24 Apr 2025 18:57:11 GMT, Jatin Bhateja  wrote:

>> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   CPUFeatures: RISC-V support
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 563:
> 
>> 561:     debug_name = debug_name_oop->const_oop()->as_instance()->java_lang_String_str(buf, buflen);
>> 562:   }
>> 563:   Node* vcall = make_runtime_call(RC_VECTOR,
> 
> By generating an upfront CallLeafVectorNode, we may miss out on performing any GVN-style optimization for trigonometric identities like the following. do you think creating a macro node which can lazily be expanded to call node during macro expansion will help.
> 
> arcsin(sin(x)) => x
> arccos(cos(x)) => x
> sin(arcsin(x) => x
> cos(arccos(x) => x

It does look attractive, but macro expansion-based solution requires JVM to internalize such operations and their properties. 

IMO a higher-level solution based on more generic JVM primitives would enable libraries to properly annotate their operations in Java bytecodes/class files, so C2 can perform such type of transformations without the need to intrinsify each individual operation first. (Think of [JDK-8218414](https://bugs.openjdk.org/browse/JDK-8218414) / [JDK-8347901](https://bugs.openjdk.org/browse/JDK-8347901) on steroids.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2059356271

From vlivanov at openjdk.org  Thu Apr 24 23:29:28 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 24 Apr 2025 23:29:28 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v14]
In-Reply-To: 
References: 
Message-ID: 

> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
> 
> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
> 
> The patch consists of the following parts:
>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
> 
> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
> 
> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
> 
> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
> 
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
> 
> Thanks!

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Improve comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24462/files
  - new: https://git.openjdk.org/jdk/pull/24462/files/585312ae..541c4d7f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=12-13

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24462/head:pull/24462

PR: https://git.openjdk.org/jdk/pull/24462

From vlivanov at openjdk.org  Thu Apr 24 23:29:29 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 24 Apr 2025 23:29:29 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v12]
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: 

On Thu, 24 Apr 2025 11:33:43 GMT, Hamlin Li  wrote:

>> FTR both `VectorSupport.getMaxLaneCount()` and `CPUFeatures` don't rely on  raw list of ISA extensions CPU supports, but only those reported by the JVM. So, if some feature support is disabled on JVM side, it won't be reported by `VM_Version` and, hence, `CPUFeatures`.
>
> Thank you for updating! Looks good for riscv. I have ran some basic tests for vector API, passed. I did not ran benchmark, as riscv & aarch64 share the same way to bridge from java to sleef.
> 
>> Does the following check catch UseRVV == false case on RISC-V?
> 
> Yes. If you don't mind, an explicit comment might be helpful. As to me "lacking vector support" here means the vector length is not large enough, but it's quite subjective, so you are on the call.
> 
>> FTR both VectorSupport.getMaxLaneCount() and CPUFeatures don't rely on raw list of ISA extensions CPU supports, but only those reported by the JVM. So, if some feature support is disabled on JVM side, it won't be reported by VM_Version and, hence, CPUFeatures.
> 
> I'm fine with this.

Thanks, I added some clarifications in the comments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2059367624

From swen at openjdk.org  Thu Apr 24 23:54:46 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 24 Apr 2025 23:54:46 GMT
Subject: RFR: 8355301: Simplify Throwable::printStackTrace by replacing
 inner class with static method [v4]
In-Reply-To: 
References: 
 <2FArm3JRh9gez7hXK0J3YS8U5tgVTCGxdd0y1qq1cLw=.9593786d-27dd-4bd7-819d-1cd4c125d0bd@github.com>
 
 
 
Message-ID: 

On Wed, 23 Apr 2025 09:05:07 GMT, Alan Bateman  wrote:

>>> Ugh, hopefully this will be replaced in the next iteration.
>> 
>> What should we replace it with? Do you have any suggestions?
>
>> What should we replace it with? Do you have any suggestions?
> 
> The wrapper classes were needed when there were was a mix of synchronized and j.u.concurrent locks in use. With JEP 491 integrated it meant that the java.io classes could be changed back to use synchronized.  Yes, we could do some cleanup in Throwable too. Changing PrintStreamOrWriter to be an interface should be fine but the rest of these changes in this PR doesn't seem necessary. As others have already asked, I think it would be useful to understand what issue you are running into and why you want to change this code.

@AlanBateman I have modified it to use interface + record. Is this what you want?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24795#discussion_r2059382954

From swen at openjdk.org  Thu Apr 24 23:59:04 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 24 Apr 2025 23:59:04 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 UTF16::compress & Unsafe::copyMemory [v3]
In-Reply-To: 
References: 
Message-ID: <4ylPeGLOvggNyPWTiJBKd3TE_5nzKQ8utxdNJCcHwns=.f7da3b19-e39d-42b2-82cc-7a823068ceb8@github.com>

> In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string.
> 
> For these scenarios, we can use the intrinsic method StringUTF16.compress and Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed.

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 optim_sb_append_chars_202504
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/StringUTF16.java
 - putCharsUnchecked
 - copyright
 - Using StringUTF16.compress to speed up LATIN1 StringBuilder append(char[])
 - Using Unsafe.copyMemory to speed up UTF16 StringBuilder append(char[])
 - add append(char[]) benchmark

-------------

Changes: https://git.openjdk.org/jdk/pull/24773/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24773&range=02
  Stats: 47 lines in 3 files changed: 40 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24773.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24773/head:pull/24773

PR: https://git.openjdk.org/jdk/pull/24773

From darcy at openjdk.org  Fri Apr 25 00:00:51 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 25 Apr 2025 00:00:51 GMT
Subject: RFR: 8355301: Simplify Throwable::printStackTrace by replacing
 inner class with static method [v4]
In-Reply-To: 
References: 
 <2FArm3JRh9gez7hXK0J3YS8U5tgVTCGxdd0y1qq1cLw=.9593786d-27dd-4bd7-819d-1cd4c125d0bd@github.com>
 
 
 
 
Message-ID: 

On Thu, 24 Apr 2025 23:52:09 GMT, Shaojin Wen  wrote:

>>> What should we replace it with? Do you have any suggestions?
>> 
>> The wrapper classes were needed when there were was a mix of synchronized and j.u.concurrent locks in use. With JEP 491 integrated it meant that the java.io classes could be changed back to use synchronized.  Yes, we could do some cleanup in Throwable too. Changing PrintStreamOrWriter to be an interface should be fine but the rest of these changes in this PR doesn't seem necessary. As others have already asked, I think it would be useful to understand what issue you are running into and why you want to change this code.
>
> @AlanBateman I have modified it to use interface + record. Is this what you want?

Again, what goal is this PR trying to accomplish?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24795#discussion_r2059386047

From fyang at openjdk.org  Fri Apr 25 00:31:48 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 25 Apr 2025 00:31:48 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v14]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 24 Apr 2025 23:29:28 GMT, Vladimir Ivanov  wrote:

>> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
>> 
>> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
>> 
>> The patch consists of the following parts:
>>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
>> 
>> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
>> 
>> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
>> 
>> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
>> 
>> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
>> 
>> Thanks!
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comments

src/hotspot/cpu/riscv/riscv.ad line 1947:

> 1945: // Vector calling convention not yet implemented.
> 1946: bool Matcher::supports_vector_calling_convention(void) {
> 1947:   return EnableVectorSupport;

You might want to remove the use of `UseVectorStubs` in `Matcher::vector_return_value` at L1951.

assert(EnableVectorSupport && UseVectorStubs, "sanity");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2059390324

From swen at openjdk.org  Fri Apr 25 00:37:45 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 25 Apr 2025 00:37:45 GMT
Subject: RFR: 8355301: Simplify Throwable::printStackTrace by replacing
 inner class with static method [v4]
In-Reply-To: 
References: 
 <2FArm3JRh9gez7hXK0J3YS8U5tgVTCGxdd0y1qq1cLw=.9593786d-27dd-4bd7-819d-1cd4c125d0bd@github.com>
 
 
 
 
 
Message-ID: <-CxqL4jCMriKJo4KeTqy0CvecGgwWkUZBC0kaulnJxA=.399c526e-0381-4b81-a1a8-e67a4d209751@github.com>

On Thu, 24 Apr 2025 23:57:56 GMT, Joe Darcy  wrote:

>> @AlanBateman I have modified it to use interface + record. Is this what you want?
>
> Again, what goal is this PR trying to accomplish?

The goal of this PR is to simplify the code by using new language features.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24795#discussion_r2059407222

From darcy at openjdk.org  Fri Apr 25 00:55:45 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 25 Apr 2025 00:55:45 GMT
Subject: RFR: 8355301: Simplify Throwable::printStackTrace by replacing
 inner class with static method [v4]
In-Reply-To: <-CxqL4jCMriKJo4KeTqy0CvecGgwWkUZBC0kaulnJxA=.399c526e-0381-4b81-a1a8-e67a4d209751@github.com>
References: 
 <2FArm3JRh9gez7hXK0J3YS8U5tgVTCGxdd0y1qq1cLw=.9593786d-27dd-4bd7-819d-1cd4c125d0bd@github.com>
 
 
 
 
 
 <-CxqL4jCMriKJo4KeTqy0CvecGgwWkUZBC0kaulnJxA=.399c526e-0381-4b81-a1a8-e67a4d209751@github.com>
Message-ID: <6CRXITuc-qRWZeM3wl7c0relBMitvp73UH_IdIT2pXg=.ef56ee57-7423-4d25-a81d-3ce85fb5ab64@github.com>

On Fri, 25 Apr 2025 00:34:39 GMT, Shaojin Wen  wrote:

>> Again, what goal is this PR trying to accomplish?
>
> The goal of this PR is to simplify the code by using new language features.

To what end?

- "I was reading Throwable and noticed this possible refactoring."
- "I've run an analysis of the JDK code base and this is the first of N patches to move to using private records."
- "With this change, metric X is Y% better."

Something else?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24795#discussion_r2059415698

From liach at openjdk.org  Fri Apr 25 00:55:45 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 25 Apr 2025 00:55:45 GMT
Subject: RFR: 8355301: Simplify Throwable::printStackTrace by replacing
 inner class with static method [v4]
In-Reply-To: <6CRXITuc-qRWZeM3wl7c0relBMitvp73UH_IdIT2pXg=.ef56ee57-7423-4d25-a81d-3ce85fb5ab64@github.com>
References: 
 <2FArm3JRh9gez7hXK0J3YS8U5tgVTCGxdd0y1qq1cLw=.9593786d-27dd-4bd7-819d-1cd4c125d0bd@github.com>
 
 
 
 
 
 <-CxqL4jCMriKJo4KeTqy0CvecGgwWkUZBC0kaulnJxA=.399c526e-0381-4b81-a1a8-e67a4d209751@github.com>
 <6CRXITuc-qRWZeM3wl7c0relBMitvp73UH_IdIT2pXg=.ef56ee57-7423-4d25-a81d-3ce85fb5ab64@github.com>
Message-ID: <3mx1ZtYp7LKGHnzcsG3xA6shmbGZ9tRtPpT0HAc9siY=.879d7f89-e7d6-4cc4-9cda-5d52cef350f9@github.com>

On Fri, 25 Apr 2025 00:52:01 GMT, Joe Darcy  wrote:

>> The goal of this PR is to simplify the code by using new language features.
>
> To what end?
> 
> - "I was reading Throwable and noticed this possible refactoring."
> - "I've run an analysis of the JDK code base and this is the first of N patches to move to using private records."
> - "With this change, metric X is Y% better."
> 
> Something else?

I think the initial version tried to use record and interfaces to simplify declarations; then I suggested that we have 3 classes, but we can just use an on-site instanceof check to reduce number of classes (which will be individual files in images, also class loading penalty for stack trace printing). However, Alan has this comment, which I don't understand quite well either - seems Alan was looking at an older revision as the interface was removed at the time of his comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24795#discussion_r2059417029

From swen at openjdk.org  Fri Apr 25 01:24:44 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 25 Apr 2025 01:24:44 GMT
Subject: RFR: 8355301: Simplify Throwable::printStackTrace by using record
 [v4]
In-Reply-To: <3mx1ZtYp7LKGHnzcsG3xA6shmbGZ9tRtPpT0HAc9siY=.879d7f89-e7d6-4cc4-9cda-5d52cef350f9@github.com>
References: 
 <2FArm3JRh9gez7hXK0J3YS8U5tgVTCGxdd0y1qq1cLw=.9593786d-27dd-4bd7-819d-1cd4c125d0bd@github.com>
 
 
 
 
 
 <-CxqL4jCMriKJo4KeTqy0CvecGgwWkUZBC0kaulnJxA=.399c526e-0381-4b81-a1a8-e67a4d209751@github.com>
 <6CRXITuc-qRWZeM3wl7c0relBMitvp73UH_IdIT2pXg=.ef56ee57-7423-4d25-a81d-3ce85fb5ab64@github.com>
 <3mx1ZtYp7LKGHnzcsG3xA6shmbGZ9tRtPpT0HAc9siY=.879d7f89-e7d6-4cc4-9cda-5d52cef350f9@github.com>
Message-ID: 

On Fri, 25 Apr 2025 00:53:35 GMT, Chen Liang  wrote:

>> To what end?
>> 
>> - "I was reading Throwable and noticed this possible refactoring."
>> - "I've run an analysis of the JDK code base and this is the first of N patches to move to using private records."
>> - "With this change, metric X is Y% better."
>> 
>> Something else?
>
> I think the initial version tried to use record and interfaces to simplify declarations; then I suggested that we have 3 classes, but we can just use an on-site instanceof check to reduce number of classes (which will be individual files in images, also class loading penalty for stack trace printing). However, Alan has this comment, which I don't understand quite well either - seems Alan was looking at an older revision as the interface was removed at the time of his comment.

I was reading `Throwable` source code and saw this and thought we could use the new language feature `record`. We should use more new language features in the core library, and this will be used as a reference.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24795#discussion_r2059430988

From jpai at openjdk.org  Fri Apr 25 02:20:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Apr 2025 02:20:54 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: 
References: 
 <9Sltn-rHaM-4yCCjxAV52Wuc2-j-Q6brdwZyP30551c=.6de1542e-d123-4b37-a199-7675c5c1d2f2@github.com>
 
Message-ID: 

On Wed, 23 Apr 2025 07:54:39 GMT, Jaikiran Pai  wrote:

>> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 366:
>> 
>>> 364:     }
>>> 365: 
>>> 366:     public String chooseServerAlias(String keyType,
>> 
>> This method should have default (package-private) access modifier.
>
> Hello Artur, you are right. This is an overisght and we'll fix this as part of the next refresh of this PR.

This is now addressed in the latest update to this PR.

>> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 375:
>> 
>>> 373:     }
>>> 374: 
>>> 375:     public String chooseClientAlias(String[] keyTypes, Principal[] issuers,
>> 
>> Same as above, the method shouldn't be public.
>
> Agreed. We will address this in the next refresh of the PR.

This is now addressed in the latest update to this PR.

>> test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 86:
>> 
>>> 84:     public static void main(String[] args) throws Exception {
>>> 85:         // re-enable 3DES
>>> 86:         Security.setProperty("jdk.tls.disabledAlgorithms", "");
>> 
>> Use `SecurityUtils.removeFromDisabledAlgs` and only remove 3DES from this property.
>
> Thank you for pointing to `SecurityUtils`. I updated this test to use that test library and the test continues to work as expected. We will include this change in the next refresh of the PR.

This too is now addressed in the latest update to this PR.

>> test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 95:
>> 
>>> 93:         //System.setProperty("javax.net.ssl.keyStorePassword", PASSWORD);
>>> 94:         //System.setProperty("javax.net.ssl.trustStore", KEYSTORE);
>>> 95:         //System.setProperty("javax.net.ssl.trustStorePassword", PASSWORD);
>> 
>> Why we don't delete this?
>
> This looks like a leftover. I'll remove this as part of the next refresh.

Addressed in the latest update to this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2059464244
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2059464328
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2059464619
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2059464758

From xgong at openjdk.org  Fri Apr 25 02:36:59 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 25 Apr 2025 02:36:59 GMT
Subject: RFR: 8351623: VectorAPI: Refactor subword gather load and add SVE
 implementation
In-Reply-To: 
References: 
Message-ID: 

On Wed, 16 Apr 2025 08:58:34 GMT, Xiaohong Gong  wrote:

> ### Summary:
> [JDK-8318650](http://java-service.client.nvidia.com/?q=8318650) added the hotspot intrinsifying of subword gather load APIs for X86 platforms [1]. This patch aims at implementing the equivalent functionality for AArch64 SVE platform. In addition to the AArch64 backend support, this patch also refactors the API implementation in Java side and the compiler mid-end part to make the operations more efficient and maintainable across different architectures.
> 
> ### Background:
> Vector gather load APIs load values from memory addresses calculated by adding a base pointer to integer indices stored in an int array. SVE provides native vector gather load instructions for byte/short types using an int vector saving indices (see [2][3]).
> 
> The number of loaded elements must match the index vector's element count. Since int elements are 4/2 times larger than byte/short elements, and given `MaxVectorSize` constraints, the operation may need to be splitted into multiple parts.
> 
> Using a 128-bit byte vector gather load as an example, there are four scenarios with different `MaxVectorSize`:
> 
> 1. `MaxVectorSize = 16, byte_vector_size = 16`:
>    - Can load 4 indices per vector register
>    - So can finish 4 bytes per gather-load operation
>    - Requires 4 times of gather-loads and final merge
>    Example:
>    ```
>    byte[] arr = [a, b, c, d, e, f, g, h, i, g, k, l, m, n, o, p, ...]
>    int[] idx = [3, 2, 4, 1, 5, 7, 5, 2, 0, 6, 7, 1, 15, 10, 11, 9]
> 
>    4 gather-load:
>    idx_v1 = [1 4 2 3]    gather_v1 = [0000 0000 0000 becd]
>    idx_v2 = [2 5 7 5]    gather_v2 = [0000 0000 0000 cfhf]
>    idx_v3 = [1 7 6 0]    gather_v3 = [0000 0000 0000 bhga]
>    idx_v4 = [9 11 10 15] gather_v4 = [0000 0000 0000 jlkp]
>    merge: v = [jlkp bhga cfhf becd]
>    ```
> 
> 2. `MaxVectorSize = 32, byte_vector_size = MaxVectorSize / 2`:
>    - Can load 8 indices per vector register
>    - So can finish 8 bytes per gather-load operation
>    - Requires 2 times of gather-loads and merge
>    Example:
>    ```
>    byte[] arr = [a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, ...]
>    int[] index = [3, 2, 4, 1, 5, 7, 5, 2, 0, 6, 7, 1, 15, 10, 11, 9]
> 
>    2 gather-load:
>    idx_v1 = [2 5 7 5 1 4 2 3]
>    idx_v2 = [9 11 10 15 1 7 6 0]
>    gather_v1 = [0000 0000 0000 0000 0000 0000 cfhf becd]
>    gather_v2 = [0000 0000 0000 0000 0000 0000 jlkp bhga]
>    merge: v = [0000 0000 0000 0000 jlkp bhga cfhf becd]
>    ```
> 
> 3. `MaxVectorSize = 64, byte_vector_size = MaxVectorSize / 4`:
>    - Can load 16 indices per vector register
>    - So can ...

I?d like to close this PR and split the change with two new PRs. Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24679#issuecomment-2829245185

From xgong at openjdk.org  Fri Apr 25 02:37:00 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 25 Apr 2025 02:37:00 GMT
Subject: Withdrawn: 8351623: VectorAPI: Refactor subword gather load and add
 SVE implementation
In-Reply-To: 
References: 
Message-ID: 

On Wed, 16 Apr 2025 08:58:34 GMT, Xiaohong Gong  wrote:

> ### Summary:
> [JDK-8318650](http://java-service.client.nvidia.com/?q=8318650) added the hotspot intrinsifying of subword gather load APIs for X86 platforms [1]. This patch aims at implementing the equivalent functionality for AArch64 SVE platform. In addition to the AArch64 backend support, this patch also refactors the API implementation in Java side and the compiler mid-end part to make the operations more efficient and maintainable across different architectures.
> 
> ### Background:
> Vector gather load APIs load values from memory addresses calculated by adding a base pointer to integer indices stored in an int array. SVE provides native vector gather load instructions for byte/short types using an int vector saving indices (see [2][3]).
> 
> The number of loaded elements must match the index vector's element count. Since int elements are 4/2 times larger than byte/short elements, and given `MaxVectorSize` constraints, the operation may need to be splitted into multiple parts.
> 
> Using a 128-bit byte vector gather load as an example, there are four scenarios with different `MaxVectorSize`:
> 
> 1. `MaxVectorSize = 16, byte_vector_size = 16`:
>    - Can load 4 indices per vector register
>    - So can finish 4 bytes per gather-load operation
>    - Requires 4 times of gather-loads and final merge
>    Example:
>    ```
>    byte[] arr = [a, b, c, d, e, f, g, h, i, g, k, l, m, n, o, p, ...]
>    int[] idx = [3, 2, 4, 1, 5, 7, 5, 2, 0, 6, 7, 1, 15, 10, 11, 9]
> 
>    4 gather-load:
>    idx_v1 = [1 4 2 3]    gather_v1 = [0000 0000 0000 becd]
>    idx_v2 = [2 5 7 5]    gather_v2 = [0000 0000 0000 cfhf]
>    idx_v3 = [1 7 6 0]    gather_v3 = [0000 0000 0000 bhga]
>    idx_v4 = [9 11 10 15] gather_v4 = [0000 0000 0000 jlkp]
>    merge: v = [jlkp bhga cfhf becd]
>    ```
> 
> 2. `MaxVectorSize = 32, byte_vector_size = MaxVectorSize / 2`:
>    - Can load 8 indices per vector register
>    - So can finish 8 bytes per gather-load operation
>    - Requires 2 times of gather-loads and merge
>    Example:
>    ```
>    byte[] arr = [a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, ...]
>    int[] index = [3, 2, 4, 1, 5, 7, 5, 2, 0, 6, 7, 1, 15, 10, 11, 9]
> 
>    2 gather-load:
>    idx_v1 = [2 5 7 5 1 4 2 3]
>    idx_v2 = [9 11 10 15 1 7 6 0]
>    gather_v1 = [0000 0000 0000 0000 0000 0000 cfhf becd]
>    gather_v2 = [0000 0000 0000 0000 0000 0000 jlkp bhga]
>    merge: v = [0000 0000 0000 0000 jlkp bhga cfhf becd]
>    ```
> 
> 3. `MaxVectorSize = 64, byte_vector_size = MaxVectorSize / 4`:
>    - Can load 16 indices per vector register
>    - So can ...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24679

From iklam at openjdk.org  Fri Apr 25 03:07:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 25 Apr 2025 03:07:41 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v2]
In-Reply-To: 
References: 
Message-ID: <9vYE-OKXhCgeECvHPTyQ9XKta9vTe9zrMRL4kJq8GPg=.38bef15e-96e6-4d01-89fe-89f75f23a278@github.com>

> This PR contains 2 parts
> 
> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.
> 
> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):
> 
> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 
> 
> `ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:
> 
> - If an entry has not yet been collected, we make sure it will never be collected.
> - If an entry has been collected, we remove it from the table
> 
> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.
> 
> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.
> 
> In the future, we may relax the implementation to allow for other use cases.

Ioi Lam has updated the pull request incrementally with three additional commits since the last revision:

 - Refactored code
 - Fixed error when running "make test JTREG=AOT_JDK=true TEST=open/test/hotspot/jtreg/runtime/invokedynamic"
 - Work around hotspot/jtreg/sources/TestNoNULL.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24757/files
  - new: https://git.openjdk.org/jdk/pull/24757/files/6678482b..2c31ca7c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24757&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24757&range=00-01

  Stats: 56 lines in 4 files changed: 35 ins; 12 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/24757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24757/head:pull/24757

PR: https://git.openjdk.org/jdk/pull/24757

From duke at openjdk.org  Fri Apr 25 03:45:10 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Fri, 25 Apr 2025 03:45:10 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v78]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 24 Apr 2025 10:37:59 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make public constuctor private

src/java.base/share/classes/java/lang/StableValue.java line 389:

> 387:  * Invocations of {@link #setOrThrow(Object)} form a total order of zero or more
> 388:  * exceptional invocations followed by zero (if the contents were already set) or one
> 389:  * successful invocation. Since stable functions and stable collections are built on top

How can an exceptional invocation of `setOrThrow` be followed by a successful invocation?

src/java.base/share/classes/java/lang/StableValue.java line 447:

> 445:         permits StableValueImpl {
> 446: 
> 447:     // Principal methods

Not important, not practical and hacky (exceptions as control flow), but technically all methods could be implemented in terms of `orElseSet`, so they could also be called "convenience methods":


trySet(c) {
    success = false
    orElseSet(() -> {success = true; return c})
    return succes
}

orElse(o) {
    try { return orElseSet(() -> throw) }
    catch { return o }
}

orElseThrow() {
    orElseSet(() -> throw)
}

isSet() {
    try { orElseSet(() -> throw) }
    catch { return false }
    return true
}

setOrThrow(c) {
    success = false
    orElseSet(() -> {success = true; return c})
    if (!success) throw
}

I guess these two comments (`// Principal methods` and `// Convenience methods`) could also just be omitted.

src/java.base/share/classes/java/lang/StableValue.java line 523:

> 521:      * @throws IllegalStateException if the contents was already set
> 522:      */
> 523:     void setOrThrow(T contents);

Should probably also mention that `IllegalStateException` can be caused by recursive initialization (see `trySet`).

src/java.base/share/classes/java/lang/StableValue.java line 577:

> 575:      * already under computation will block until a value is computed or an exception is
> 576:      * thrown by the computing thread. The computing threads will then observe the newly
> 577:      * computed value (if any) and will then never execute.

This sentence seems off. I think it should say "competing threads" instead of "computing threads". And what will they never execute?

src/java.base/share/classes/java/lang/StableValue.java line 688:

> 686:      * 

> 687:      * Any direct {@link List#subList(int, int) subList} or {@link List#reversed()} views
> 688:      * of the returned list are also stable.

What about non-direct views? I think they could be made stable (i.e. have a non-evaluating `toString`) with few changes:

Override `subList` in `ImmutableCollections.StableList.StableReverseOrderListView` similar to `ReverseOrderListView.subList`:

@Override
public List subList(int fromIndex, int toIndex) {
    int size = base.size();
    subListRangeCheck(fromIndex, toIndex, size);
    return new StableReverseOrderListView<>(base.subList(size - toIndex, size - fromIndex));
}


Override `reversed` in `ImmutableCollections.SubList`:

@Override
public List reversed() {
    if (root instanceof StableList) {
        return new StableList.StableReverseOrderListView<>(this);
    } else {
        return super.reversed();
    }
}


Change `ImmutableCollections.StableList.StableReverseOrderListView.toString` (instead of copying and reversing, `StableUtil.renderElements` could also be modified to have a configurable iteration order):

@Override
public String toString() {
    final StableList stable;
    final int from, to;
    if (base instanceof SubList sub) {
        stable = (StableList)sub.root;
        from = sub.offset;
        to = sub.offset + sub.size();
    } else {
        stable = (StableList)base;
        from = 0;
        to = stable.delegates.length;
    }
    final StableValueImpl[] reversed = ArraysSupport.reverse(
            Arrays.copyOfRange(stable.delegates, from, to));
    return StableUtil.renderElements(this, "StableList", reversed);
}


That should make sure that however many times and in whatever combination `reversed` and `subList` are called on a stable list, it will always be an instance of `ImmutableCollections.StableList`, `ImmutableCollections.StableList.StableReverseOrderListView` or `ImmutableCollections.SubList`. They all properly override `toString`. The view nesting depth is also bounded.

Visualized as a table (`SL` = `ImmutableCollections.StableList`, `Rev` = `ImmutableCollections.StableList.StableReverseOrderListView`, `Sub` = `ImmutableCollections.SubList`):
| view nesting  | calling `reversed` on that view returns | calling `subList` on that view returns |
| ------------- | --------------------------------------- | -------------------------------------- |
| `SL`          | `Rev(SL)`                               | `Sub(SL)`                              |
| `Rev(SL)`     | `SL`                                    | `Rev(Sub(SL))`                         |
| `Sub(SL)`     | `Rev(Sub(SL)`                           | `Sub(SL)`                              |
| `Rev(Sub(SL)` | `Sub(SL)`                               | `Rev(Sub(SL))`                         |

src/java.base/share/classes/java/lang/StableValue.java line 731:

> 729:      * 

> 730:      * Any direct {@link Map#values()} or {@link Map#entrySet()} views
> 731:      * of the returned map are also stable.

"direct views" implies there are non-direct views. What would these be? `Collection` and `Set` have no methods that return views. The only non-direct view I can think of are the `Map.Entry` instances in the entry set, but see https://github.com/openjdk/jdk/pull/23972#discussion_r2050713377.

src/java.base/share/classes/java/util/ImmutableCollections.java line 270:

> 268:         // A lazy list is not Serializable so, we cannot return `List.of()` if size == 0
> 269:         return new StableList<>(size, mapper);
> 270:     }

Why have this function for stable lists but not for maps? Also uses "lazy list" instead of "stable list" in the comment.

src/java.base/share/classes/java/util/ImmutableCollections.java line 578:

> 576:         public String toString() {
> 577:             if (root instanceof StableList stableList) {
> 578:                 return StableUtil.renderElements(root, "StableList", stableList.delegates, offset, size);

Suggestion:

                return StableUtil.renderElements(this, "StableList", stableList.delegates, offset, size);

Other view collections (`ArrayList.SubList`, `ReverseOrderListView`, `AbstractMap.keySet`, `AbstractMap.values`, `HashMap.EntrySet`) use the view reference (and not the underlying collection) for detecting self containment, so `renderElements` should use `this` instead of `root` for `self`.

src/java.base/share/classes/java/util/ImmutableCollections.java line 898:

> 896:                 final StableValueImpl[] reversed = ArraysSupport.reverse(
> 897:                         Arrays.copyOf(delegates, delegates.length));
> 898:                 return StableUtil.renderElements(base, "Collection", reversed);

Suggestion:

                return StableUtil.renderElements(this, "StableList", reversed);

All other calls use "Stable...". Other view collections (`ArrayList.SubList`, `ReverseOrderListView`, `AbstractMap.keySet`, `AbstractMap.values`, `HashMap.EntrySet`) use the view reference (and not the underlying collection) for detecting self containment, so `renderElements` should use `this` instead of `base` for `self`.

src/java.base/share/classes/java/util/ImmutableCollections.java line 1660:

> 1658:             public String toString() {
> 1659:                 final StableValueImpl[] values = delegate.values().toArray(GENERATOR);
> 1660:                 return StableUtil.renderElements(StableMap.this, "StableMap", values);

Suggestion:

                return StableUtil.renderElements(this, "StableCollection", values);

Other view collections (`ArrayList.SubList`, `ReverseOrderListView`, `AbstractMap.keySet`, `AbstractMap.values`, `HashMap.EntrySet`) use the view reference (and not the underlying collection) for detecting self containment, so `renderElements` should use `this` instead of `StableMap.this` for `self`. `ImmutableCollections.StableMap.StableMapValues` is a `Collection`, not a `Map`, so use `"StableCollection"` instead of `"StableMap"`.

src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 51:

> 49:  * @param firstOrdinal the lowest ordinal used
> 50:  * @param delegates    a delegate array of inputs to StableValue mappings
> 51:  * @param original     the original Function

Are `enumType` and `member` missing intentionally?

src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 70:

> 68:         // Since we did the member.test above, we know the index is in bounds
> 69:         delegate = delegates[index];
> 70:         return delegate.orElseSet(new Supplier() {

Suggestion:

        // Since we did the member.test above, we know the index is in bounds
        return delegates[index].orElseSet(new Supplier() {

I don't think the local variable is needed here.

src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 88:

> 86:     public String toString() {
> 87:         final E[] enumElements = enumType.getEnumConstants();
> 88:         final Collection>> entries = new ArrayList<>(enumElements.length);

Suggestion:

        final Collection>> entries = new ArrayList<>(delegates.length);

Otherwise the list is bigger than needed (even `delegates.length` could be too big but should always be smaller than `enumElements.length`).

src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 102:

> 100:                                                               Function original) {
> 101:         // The input set is not empty
> 102:         final Class enumType = (Class)inputs.iterator().next().getClass();

Suggestion:

        final Class enumType = ((E)inputs.iterator().next()).getDeclaringClass();

`Class.getEnumConstants` returns `null` for the class object of an enum constant with a body. This would lead to a NPE in the next line.

This code should trigger it:

enum E {
    A, B { public String toString() { return "b"; } }
}

StableValue.function(EnumSet.of(E.B), x -> x);

src/java.base/share/classes/jdk/internal/lang/stable/StableFunction.java line 35:

> 33: import java.util.function.Supplier;
> 34: 
> 35: // Note: It would be possible to just use `LazyMap::get` with some additional logic

Is there a class named `LazyMap`? Or was this comment not updated to use the "stable" term?

src/java.base/share/classes/jdk/internal/lang/stable/StableIntFunction.java line 36:

> 34: // Note: It would be possible to just use `LazyList::get` instead of this
> 35: // class but explicitly providing a class like this provides better
> 36: // debug capability, exception handling, and may provide better performance.

This comment seems somewhat redundant, at least performance is already mentioned in the javadoc comment right beneath it. Also `LazyList`, see my comment for `StableFunction`.

src/java.base/share/classes/jdk/internal/lang/stable/StableUtil.java line 69:

> 67:             final String valueString;
> 68:             if (value == self) {
> 69:                 valueString = ("(this ") + selfName + ")";

Suggestion:

                valueString = "(this " + selfName + ")";

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 57:

> 55:             UNSAFE.objectFieldOffset(StableValueImpl.class, "contents");
> 56:     // Used to indicate a holder value is `null` (see field `value` below)
> 57:     // A wrapper method `nullSentinel()` is used for generic type conversion.

Suggestion:

    // Used to indicate a holder value is `null` (see field `contents` below)

The `nullSentinel` method no longer exists, the field is named `contents`.

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 86:

> 84:         preventReentry();
> 85:         // Mutual exclusion is required here as `orElseSet` might also
> 86:         // attempt to modify the `wrappedValue`

Suggestion:

        // attempt to modify `this.contents`

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 161:

> 159: 
> 160:     @ForceInline
> 161:     public Object wrappedContentAcquire() {

Maybe name it `wrappedContentsAcquire` (with an "s")? It's called "contents" elsewhere.

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 188:

> 186:      */
> 187:     @ForceInline
> 188:     private boolean wrapAndSet(Object newValue) {

Suggestion:

    private boolean wrapAndSet(T newValue) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2058468433
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2058510873
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2058567306
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2058875533
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2058903119
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2058900859
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2059151416
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2059388757
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2059383526
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2059476366
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2058957558
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2058968283
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2058974011
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2059008635
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2058940541
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2058945089
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2059387502
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2058555891
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2058574430
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2058598520
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2058662923

From duke at openjdk.org  Fri Apr 25 03:45:10 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Fri, 25 Apr 2025 03:45:10 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v56]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 22 Apr 2025 11:22:52 GMT, Per Minborg  wrote:

>> src/java.base/share/classes/java/util/ImmutableCollections.java line 1592:
>> 
>>> 1590:                     final K k = inner.getKey();
>>> 1591:                     return new NullableKeyValueHolder<>(k, inner.getValue().orElseSet(new Supplier() {
>>> 1592:                         @Override public V get() { return mapper.apply(k); }}));
>> 
>> I suppose you could potentially make this more lazy by returning an `Entry` implementation that only evaluates the mapper when calling `Entry::getValue`.
>
> Yepp. Interesting idea.

This lazy `Entry` implementation should then also have a `toString` that doesn't evaluate the contents. It should also be used in `forEachRemaining`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2059377365

From iklam at openjdk.org  Fri Apr 25 04:08:32 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 25 Apr 2025 04:08:32 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v3]
In-Reply-To: 
References: 
Message-ID: 

> This PR contains 2 parts
> 
> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.
> 
> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):
> 
> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 
> 
> `ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:
> 
> - If an entry has not yet been collected, we make sure it will never be collected.
> - If an entry has been collected, we remove it from the table
> 
> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.
> 
> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.
> 
> In the future, we may relax the implementation to allow for other use cases.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Fixed windows path issues

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24757/files
  - new: https://git.openjdk.org/jdk/pull/24757/files/2c31ca7c..643eec2a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24757&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24757&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24757/head:pull/24757

PR: https://git.openjdk.org/jdk/pull/24757

From ccheung at openjdk.org  Fri Apr 25 04:23:12 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 25 Apr 2025 04:23:12 GMT
Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking [v7]
In-Reply-To: 
References: 
Message-ID: 

> This RFE allows --add-opens to be specified for AOT cache creation. AOT cache can be used during production run with --add-opens option as long as the same set of options is used during assembly phase.
> 
> Passed tiers 1 - 4 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  remove call to addExtraExportsAndOpens() in ModuleBootstrap.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24695/files
  - new: https://git.openjdk.org/jdk/pull/24695/files/0f28e07b..4b4d4f50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24695&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24695&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24695.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24695/head:pull/24695

PR: https://git.openjdk.org/jdk/pull/24695

From iklam at openjdk.org  Fri Apr 25 04:53:46 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 25 Apr 2025 04:53:46 GMT
Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 25 Apr 2025 04:23:12 GMT, Calvin Cheung  wrote:

>> This RFE allows --add-opens to be specified for AOT cache creation. AOT cache can be used during production run with --add-opens option as long as the same set of options is used during assembly phase.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove call to addExtraExportsAndOpens() in ModuleBootstrap.java

Marked as reviewed by iklam (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24695#pullrequestreview-2792985774

From vlivanov at openjdk.org  Fri Apr 25 05:26:35 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 25 Apr 2025 05:26:35 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v15]
In-Reply-To: 
References: 
Message-ID: 

> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
> 
> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
> 
> The patch consists of the following parts:
>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
> 
> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
> 
> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
> 
> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
> 
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
> 
> Thanks!

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Remove UseVectorStubs usage in riscv.ad

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24462/files
  - new: https://git.openjdk.org/jdk/pull/24462/files/541c4d7f..f4373e41

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24462&range=13-14

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24462/head:pull/24462

PR: https://git.openjdk.org/jdk/pull/24462

From vlivanov at openjdk.org  Fri Apr 25 05:26:35 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 25 Apr 2025 05:26:35 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v14]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 25 Apr 2025 00:06:28 GMT, Fei Yang  wrote:

>> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comments
>
> src/hotspot/cpu/riscv/riscv.ad line 1947:
> 
>> 1945: // Vector calling convention not yet implemented.
>> 1946: bool Matcher::supports_vector_calling_convention(void) {
>> 1947:   return EnableVectorSupport;
> 
> You might also want to remove the use of `UseVectorStubs` in `Matcher::vector_return_value` at L1951.
> 
> assert(EnableVectorSupport && UseVectorStubs, "sanity");

Good catch. Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2059577657

From alanb at openjdk.org  Fri Apr 25 05:29:44 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Apr 2025 05:29:44 GMT
Subject: RFR: 8355524: Only every second line in upgradeable files is being
 used
In-Reply-To: 
References: 
Message-ID: <6akhzN-jhXEePjUUKwh_YaTUf5MNRIAYczIUOvBv5o8=.6e95cb1d-d3f4-4ef8-b438-fba31d29fa94@github.com>

On Thu, 24 Apr 2025 17:31:50 GMT, Severin Gehwolf  wrote:

> Please review this fix to [JDK-8353185](https://bugs.openjdk.org/browse/JDK-8353185). The reading logic for the config file would erroneously use `scanner.nextLine()` when the current line to be added is in `line`. `line` is not being added, but `scanner.nextLine()` unintentionally skipping lines. The config file has a change too. It moves the `tzdb.dat` line last so that the existing test verifies that the `cacerts` one isn't being skipped. This slipped through because `tzdb.dat` updates aren't automatically tested.
> 
> Testing:
> - [ ] GHA
> - [x] The test from [JDK-8353185](https://bugs.openjdk.org/browse/JDK-8353185), `UpgradeableFileCacertsTest.java` fails with the config file change only (without the product fix) and passes with the one-liner. Also some manual testing when both files have been upgraded.
> 
> Thoughts?

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24855#pullrequestreview-2793024177

From iklam at openjdk.org  Fri Apr 25 05:56:15 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 25 Apr 2025 05:56:15 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v4]
In-Reply-To: 
References: 
Message-ID: 

> This PR contains 2 parts
> 
> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.
> 
> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):
> 
> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 
> 
> `ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:
> 
> - If an entry has not yet been collected, we make sure it will never be collected.
> - If an entry has been collected, we remove it from the table
> 
> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.
> 
> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.
> 
> In the future, we may relax the implementation to allow for other use cases.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @fisk comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24757/files
  - new: https://git.openjdk.org/jdk/pull/24757/files/643eec2a..bba16eef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24757&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24757&range=02-03

  Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24757/head:pull/24757

PR: https://git.openjdk.org/jdk/pull/24757

From alanb at openjdk.org  Fri Apr 25 06:09:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Apr 2025 06:09:05 GMT
Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 25 Apr 2025 04:23:12 GMT, Calvin Cheung  wrote:

>> This RFE allows --add-opens to be specified for AOT cache creation. AOT cache can be used during production run with --add-opens option as long as the same set of options is used during assembly phase.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove call to addExtraExportsAndOpens() in ModuleBootstrap.java

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24695#pullrequestreview-2793081603

From alanb at openjdk.org  Fri Apr 25 06:32:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Apr 2025 06:32:15 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v78]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 24 Apr 2025 10:37:59 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make public constuctor private

src/java.base/share/classes/java/lang/StableValue.java line 470:

> 468:      * @param other to return if the contents is not set
> 469:      */
> 470:     T orElse(T other);

Just to note that JEP 506 is proposing to change ScopedValue.orElse to disallow null. A ScopedValue can be bound to null (e.g. usage in Subject API) so using orElse(null) is problematic. A orNull may be added later if needed. As a StableValue can hold null then it's similar and might be surprising to developers to have the two APIs be different here. Something to look at again after JEP 502 is integrated, I'm not suggesting changing anything in this PR of course.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2059637511

From alanb at openjdk.org  Fri Apr 25 07:09:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Apr 2025 07:09:01 GMT
Subject: RFR: 8355301: Simplify Throwable::printStackTrace by using record
 [v4]
In-Reply-To: 
References: 
 <2FArm3JRh9gez7hXK0J3YS8U5tgVTCGxdd0y1qq1cLw=.9593786d-27dd-4bd7-819d-1cd4c125d0bd@github.com>
 
 
 
Message-ID: 

On Wed, 23 Apr 2025 09:05:07 GMT, Alan Bateman  wrote:

>>> Ugh, hopefully this will be replaced in the next iteration.
>> 
>> What should we replace it with? Do you have any suggestions?
>
>> What should we replace it with? Do you have any suggestions?
> 
> The wrapper classes were needed when there were was a mix of synchronized and j.u.concurrent locks in use. With JEP 491 integrated it meant that the java.io classes could be changed back to use synchronized.  Yes, we could do some cleanup in Throwable too. Changing PrintStreamOrWriter to be an interface should be fine but the rest of these changes in this PR doesn't seem necessary. As others have already asked, I think it would be useful to understand what issue you are running into and why you want to change this code.

> @AlanBateman I have modified it to use interface + record. Is this what you want?

I don't object to changing it to interface + record but it feels more like needless code churn. I really disliked the next version that used printStackTrace0(Object printer) as it immediately invites another re-write.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24795#discussion_r2059679772

From jpai at openjdk.org  Fri Apr 25 07:21:47 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Apr 2025 07:21:47 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value
In-Reply-To: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
Message-ID: 

On Thu, 24 Apr 2025 20:46:42 GMT, Brian Burkhalter  wrote:

> Use the `@requires` tag instead of obtaining the operating system name from the `os.name` property and then exiting if the test is not run on that operating system.

test/jdk/java/io/File/MacPathTest.java line 28:

> 26:  * @summary Tests paths on macOS
> 27:  * @requires (os.family == "mac")
> 28:  */

The missing `@test` on this looked odd, since that would mean that this test wasn't being run at all so far.

I went back and looked at the original RFR which introduced this test for https://bugs.openjdk.org/browse/JDK-7130915. The RFR is here https://mail.openjdk.org/pipermail/core-libs-dev/2012-June/010621.html. Going through the webrevs posted there, it appears that this was initially a shell test and had `@test` declaration.

Then in https://bugs.openjdk.org/browse/JDK-8181912 we refactored it to be a java jtreg test. The RFR for that is here https://mail.openjdk.org/pipermail/core-libs-dev/2017-June/048225.html. Going through this refactor RFR, the final webrev that was settled upon and integrated appears to be this https://mail.openjdk.org/pipermail/core-libs-dev/2017-June/048319.html. So what that refactoring did was (https://cr.openjdk.org/~mli/8181912/webrev.01/) it moved the `@test` declaration to a new file `test/java/io/File/MacPath.java` which is what then launches this `test/jdk/java/io/File/MacPathTest.java`'s main method using `ProcessBuilder`. So this `MacPathTest.java` isn't really the jtreg `@test`. 

Given this, i think we shouldn't be adding this `@test` declaration here and `MacPath.java` already has the necessary `@requires (os.family == "mac")`. 

What we should probably do (if you prefer in a different issue/PR), is perhaps add a comment to this file that it gets launched through `MacPath.java` and also maybe remove the `os.name` checks in the `main()` method of this class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24860#discussion_r2059696724

From duke at openjdk.org  Fri Apr 25 07:24:15 2025
From: duke at openjdk.org (erifan)
Date: Fri, 25 Apr 2025 07:24:15 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> This patch optimizes the following patterns:
> For integer types:
> 
> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>     => (VectorMaskCmp src1 src2 ncond)
> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>     => (VectorMaskCmp src1 src2 ncond)
> 
> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond.
> 
> For float and double types:
> 
> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
>     => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
> 
> cond can be eq or ne.
> 
> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`:
> 
> Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
> testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
> testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
> testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
> testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
> testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
> testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
> testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
> testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
> testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
> testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4714008.434	1681.10365	1.41
> testCompareGTMaskNotByte	ops/s	7910823.674	2993.367032	10245063.58	9774.75138	1.29
> testCompareGTMaskNotInt		ops/s	1673393.928	3153.099431	2353654.521	1190.848583	1.4
> testCompareGTMaskNotLong	ops/s	849405.9159	2432.858159	1177952.041	359.96413	1.38
> testCompareGTMaskNotShort	ops/s	3339509.141	3339.976585	4711442.496	2673.364893	1.41
> testCompareLEMaskNotByte	ops/s	7911340.004	3114.69191	10231626.5	27134.20035	1.29
> testCompareLEMaskNotInt		ops/s	1675812.113	1340.969885	2353255.341	1452.4522	1.4
> testCompareLEMaskNotLong	ops/s	848862.8036	6564.841731	1177763.623	539.290106	1.38
> testCompareLEMaskNotShort	ops/s	3324951.54	2380.29473	4712116.251	1544.559684	1.41
> testCompareLTMaskNotByte	ops/s	7910390.844	2630.861436	10239567.69	6487.441672	1.29
> testCompareLTMaskNotInt		ops/s	1672180.09	995.238142	2353757.863	853.774734	1.4
> testCompareLTMaskNotLong	ops/s	856502.26...

erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Addressed some review comments
   
   1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
   2. Improve code comments.
 - Merge branch 'master' into JDK-8354242
 - Merge branch 'master' into JDK-8354242
 - 8354242: VectorAPI: combine vector not operation with compare
   
   This patch optimizes the following patterns:
   For integer types:
   ```
   (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
       => (VectorMaskCmp src1 src2 ncond)
   (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
       => (VectorMaskCmp src1 src2 ncond)
   ```
   cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the
   negative comparison of cond.
   
   For float and double types:
   ```
   (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1))
       => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
   (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1))
       => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))
   ```
   cond can be eq or ne.
   
   Benchmarks on Nvidia Grace machine with 128-bit SVE2:
   With option `-XX:UseSVE=2`:
   ```
   Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
   testCompareEQMaskNotByte	ops/s	7912127.225	2677.289518	10266136.26	8955.008548	1.29
   testCompareEQMaskNotDouble	ops/s	884737.6799	446.963779	1179760.772	448.031844	1.33
   testCompareEQMaskNotFloat	ops/s	1765045.787	682.332214	2359520.803	896.305743	1.33
   testCompareEQMaskNotInt		ops/s	1787221.411	977.743935	2353952.519	960.069976	1.31
   testCompareEQMaskNotLong	ops/s	895297.1974	673.44808	1178449.02	323.804205	1.31
   testCompareEQMaskNotShort	ops/s	3339987.002	3415.2226	4712761.965	2110.862053	1.41
   testCompareGEMaskNotByte	ops/s	7907615.16	4094.243652	10251646.9	9486.699831	1.29
   testCompareGEMaskNotInt		ops/s	1683738.958	4233.813092	2352855.205	1251.952546	1.39
   testCompareGEMaskNotLong	ops/s	854496.1561	8594.598885	1177811.493	521.1229	1.37
   testCompareGEMaskNotShort	ops/s	3341860.309	1578.975338	4714008.434	1681.10365	1.41
   testCompareGTMaskNotByte	ops/s	7910823.674	2993.367032	10245063.58	9774.75138	1.29
   testCompareGTMaskNotInt		ops/s	1673393.928	3153.099431	2353654.521	1190.848583	1.4
   testCompareGTMaskNotLong	ops/s	849405.9159	2432.858159	1177952.041	359.96413	1.38
   testCompareGTMaskNotShort	ops/s	3339509.141	3339.976585	4711442.496	2673.364893	1.41
   testCompareLEMaskNotByte	ops/s	7911340.004	3114.69191	10231626.5	27134.20035	1.29
   testCompareLEMaskNotInt		ops/s	1675812.113	1340.969885	2353255.341	1452.4522	1.4
   testCompareLEMaskNotLong	ops/s	848862.8036	6564.841731	1177763.623	539.290106	1.38
   testCompareLEMaskNotShort	ops/s	3324951.54	2380.29473	4712116.251	1544.559684	1.41
   testCompareLTMaskNotByte	ops/s	7910390.844	2630.861436	10239567.69	6487.441672	1.29
   testCompareLTMaskNotInt		ops/s	1672180.09	995.238142	2353757.863	853.774734	1.4
   testCompareLTMaskNotLong	ops/s	856502.2695	12276.82851	1177671.815	496.723302	1.37
   testCompareLTMaskNotShort	ops/s	3325798.025	2412.702501	4711554.181	1779.302112	1.41
   testCompareNEMaskNotByte	ops/s	7910002.518	2771.82477	10245315.33	16321.93935	1.29
   testCompareNEMaskNotDouble	ops/s	863754.6022	523.140788	1179133.982	476.572178	1.36
   testCompareNEMaskNotFloat	ops/s	1723321.883	2598.484803	2358492.186	877.1401	1.36
   testCompareNEMaskNotInt		ops/s	1670288.841	751.774826	2354158.125	835.720163	1.4
   testCompareNEMaskNotLong	ops/s	836327.6835	410.525466	1178178.825	308.757932	1.4
   testCompareNEMaskNotShort	ops/s	3327815.841	1511.978763	4711379.136	2336.505531	1.41
   testCompareUGEMaskNotByte	ops/s	7906699.024	3200.936474	10253843.74	15067.59401	1.29
   testCompareUGEMaskNotInt	ops/s	1674003.923	3287.191727	2353340.666	951.381021	1.4
   testCompareUGEMaskNotLong	ops/s	852424.5562	8920.408939	1177943.609	389.6621	1.38
   testCompareUGEMaskNotShort	ops/s	3327255.858	1584.885143	4711622.355	1247.215277	1.41
   testCompareUGTMaskNotByte	ops/s	7909249.189	4435.283667	10245541.34	10993.34739	1.29
   testCompareUGTMaskNotInt	ops/s	1693713.433	20650.00213	2353153.787	1055.343846	1.38
   testCompareUGTMaskNotLong	ops/s	851022.3395	7079.065268	1177910.677	538.604598	1.38
   testCompareUGTMaskNotShort	ops/s	3327236.988	1616.886789	4711209.865	3098.494145	1.41
   testCompareULEMaskNotByte	ops/s	7909350.825	3251.262342	10261449.03	7273.831341	1.29
   testCompareULEMaskNotInt	ops/s	1672350.925	1545.304304	2353231.755	914.231193	1.4
   testCompareULEMaskNotLong	ops/s	853349.4765	9804.906913	1177967.254	435.044367	1.38
   testCompareULEMaskNotShort	ops/s	3325757.891	1555.062257	4712873.187	1650.986905	1.41
   testCompareULTMaskNotByte	ops/s	7912218.621	2633.477744	10242095.98	21921.39902	1.29
   testCompareULTMaskNotInt	ops/s	1673994.849	2672.507666	2353449.22	946.105757	1.4
   testCompareULTMaskNotLong	ops/s	849032.5868	10406.06689	1177586.047	506.541456	1.38
   testCompareULTMaskNotShort	ops/s	3328062.026	1892.991844	4713247.216	1855.983724	1.41
   
   ```
   With option `-XX:UseSVE=0`:
   ```
   Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
   testCompareEQMaskNotByte	ops/s	7895961.919	72712.90804	7746493.731	71481.92938	0.98
   testCompareEQMaskNotDouble	ops/s	789811.0455	384.493088	766473.7994	2216.581793	0.97
   testCompareEQMaskNotFloat	ops/s	1806305.818	638.010451	1819616.613	3295.38958	1
   testCompareEQMaskNotInt		ops/s	1815820.144	1225.336135	1849538.401	766.29902	1.01
   testCompareEQMaskNotLong	ops/s	807336.492	335.451807	792732.9483	277.954432	0.98
   testCompareEQMaskNotShort	ops/s	4818266.38	1927.862665	4668903.001	1922.782715	0.96
   testCompareGEMaskNotByte	ops/s	7818439.678	75374.97739	16498003.98	41440.49653	2.11
   testCompareGEMaskNotInt		ops/s	1815159.05	1090.912209	2372095.779	1664.397112	1.3
   testCompareGEMaskNotLong	ops/s	804324.5575	2301.686878	927919.8507	371.766719	1.15
   testCompareGEMaskNotShort	ops/s	4818966.563	2443.643652	5385561.038	29558.37423	1.11
   testCompareGTMaskNotByte	ops/s	7893406.157	82687.74264	16470663.2	22165.55812	2.08
   testCompareGTMaskNotInt		ops/s	1815316.812	915.894106	2370447.198	655.016338	1.3
   testCompareGTMaskNotLong	ops/s	807019.456	526.525482	928079.0541	330.582693	1.15
   testCompareGTMaskNotShort	ops/s	4820552.881	1684.247747	5355902.93	5893.2915	1.11
   testCompareLEMaskNotByte	ops/s	7816263.323	79560.0015	16473621.19	56688.99585	2.1
   testCompareLEMaskNotInt		ops/s	1814915.724	926.998625	2368790.306	932.594778	1.3
   testCompareLEMaskNotLong	ops/s	806483.9	935.718082	928110.9074	407.096695	1.15
   testCompareLEMaskNotShort	ops/s	4813660.241	6817.870509	5357107.852	10061.47975	1.11
   testCompareLTMaskNotByte	ops/s	7838948.962	69136.4504	16424405.96	24464.75469	2.09
   testCompareLTMaskNotInt		ops/s	1815056.833	1187.6453	2369892.187	1103.819634	1.3
   testCompareLTMaskNotLong	ops/s	806602.1804	287.923365	928346.4118	617.682824	1.15
   testCompareLTMaskNotShort	ops/s	4817940.643	2767.1509	5372537.84	15397.47169	1.11
   testCompareNEMaskNotByte	ops/s	9078493.798	4630.339307	16484348.42	18925.88346	1.81
   testCompareNEMaskNotDouble	ops/s	661769.6272	398.712981	926763.5839	1808.843788	1.4
   testCompareNEMaskNotFloat	ops/s	1570527.252	563.642144	2312425.678	1815.844846	1.47
   testCompareNEMaskNotInt		ops/s	1619146.58	626.793854	2369711.543	942.330478	1.46
   testCompareNEMaskNotLong	ops/s	680201.5381	2252.836482	927808.6147	414.917863	1.36
   testCompareNEMaskNotShort	ops/s	3763508.054	3622.560798	5367808.015	8591.466599	1.42
   testCompareUGEMaskNotByte	ops/s	7886373.129	75917.74675	16480928.93	27524.31005	2.08
   testCompareUGEMaskNotInt	ops/s	1815636.832	750.036241	2369683.015	901.609404	1.3
   testCompareUGEMaskNotLong	ops/s	806862.5826	287.819616	928001.4394	361.063837	1.15
   testCompareUGEMaskNotShort	ops/s	4820581.361	2098.537435	5375854.248	25619.40165	1.11
   testCompareUGTMaskNotByte	ops/s	7891591.465	96614.93542	16410405.93	15012.37096	2.07
   testCompareUGTMaskNotInt	ops/s	1814871.179	662.825588	2371325.903	1170.491164	1.3
   testCompareUGTMaskNotLong	ops/s	804013.7658	2240.534209	928062.2169	531.306897	1.15
   testCompareUGTMaskNotShort	ops/s	4818150.337	3051.717685	5381449.337	21212.34187	1.11
   testCompareULEMaskNotByte	ops/s	7831540.628	81306.67253	16495250.78	38682.19675	2.1
   testCompareULEMaskNotInt	ops/s	1814484.14	687.860656	2369265.075	940.609586	1.3
   testCompareULEMaskNotLong	ops/s	807780.5749	769.876816	927538.0732	1278.267724	1.14
   testCompareULEMaskNotShort	ops/s	4817437.42	5141.336541	5356183.359	7015.608124	1.11
   testCompareULTMaskNotByte	ops/s	7849078.225	56753.59764	16395975.27	34043.67295	2.08
   testCompareULTMaskNotInt	ops/s	1814328.226	2697.219111	2370700.47	1991.841988	1.3
   testCompareULTMaskNotLong	ops/s	807166.8197	253.061506	927926.2803	252.933462	1.14
   testCompareULTMaskNotShort	ops/s	4821098.216	1625.959044	5348980.243	4100.768121	1.1
   ```
   
   Benchmarks on AMD EPYC 9124 16-Core Processor:
   With option `-XX:UseAVX=3`:
   ```
   Benchmark			Unit	Before		Score Error	After		Score Error	Uplift
   testCompareEQMaskNotByte	ops/s	16607323.35	1233692.631	18381557.66	1163201.522	1.1
   testCompareEQMaskNotDouble	ops/s	2114285.245	58782.2534	2959946.353	43016.0445	1.39
   testCompareEQMaskNotFloat	ops/s	4480874.437	89975.29074	6960151.436	64799.143	1.55
   testCompareEQMaskNotInt		ops/s	4370906.91	51784.80889	6856955.043	313858.5504	1.56
   testCompareEQMaskNotLong	ops/s	2080065.895	26762.06732	2939142.143	67179.05314	1.41
   testCompareEQMaskNotShort	ops/s	7968282.563	210437.2781	12701214.56	473152.6407	1.59
   testCompareGEMaskNotByte	ops/s	18419141.89	473408.9451	19880059.68	321638.0397	1.07
   testCompareGEMaskNotInt		ops/s	4419015.62	77352.98633	7037639.227	151066.0383	1.59
   testCompareGEMaskNotLong	ops/s	2147982.48	49227.42782	3000275.928	39298.75344	1.39
   testCompareGEMaskNotShort	ops/s	8469039.613	17833.19707	12288229.49	244317.8812	1.45
   testCompareGTMaskNotByte	ops/s	18728997.5	468328.8358	20544730.05	392264.6466	1.09
   testCompareGTMaskNotInt		ops/s	4510009.705	78812.57357	7364629.942	70970.78473	1.63
   testCompareGTMaskNotLong	ops/s	2124104.969	40917.89257	2953536.279	35199.19687	1.39
   testCompareGTMaskNotShort	ops/s	8690557.621	311534.1159	12344017.51	457931.8741	1.42
   testCompareLEMaskNotByte	ops/s	17758400.53	478383.4945	19209183.26	1143297.241	1.08
   testCompareLEMaskNotInt		ops/s	4363664.862	43443.18063	7054093.064	78141.11476	1.61
   testCompareLEMaskNotLong	ops/s	2068632.213	29844.78023	2954766.412	50667.22502	1.42
   testCompareLEMaskNotShort	ops/s	8637608.548	183538.5511	12719010.27	473568.8825	1.47
   testCompareLTMaskNotByte	ops/s	14406138.95	423105.0163	17292417.96	371386.9689	1.2
   testCompareLTMaskNotInt		ops/s	4546707.266	131977.3144	7040483.394	213590.4657	1.54
   testCompareLTMaskNotLong	ops/s	2123277.356	47243.21499	2848720.442	58896.97045	1.34
   testCompareLTMaskNotShort	ops/s	7570169.363	649873.6295	11945383.75	988276.5955	1.57
   testCompareNEMaskNotByte	ops/s	18274529.55	683396.7384	19081938.8	1118739.778	1.04
   testCompareNEMaskNotDouble	ops/s	2112533.61	43295.50012	2912115.441	78189.51083	1.37
   testCompareNEMaskNotFloat	ops/s	4628683.814	93817.07362	6967208.729	145135.8544	1.5
   testCompareNEMaskNotInt		ops/s	4470900.214	75974.50842	7286913.662	116328.5277	1.62
   testCompareNEMaskNotLong	ops/s	2134091.061	46377.94061	2934667.477	81675.46021	1.37
   testCompareNEMaskNotShort	ops/s	8790384.287	396161.8599	13076858.35	286272.1155	1.48
   testCompareUGEMaskNotByte	ops/s	18009150.9	660803.8886	17551258.33	1667014.843	0.97
   testCompareUGEMaskNotInt	ops/s	4442928.74	83190.81019	6854088.277	329008.8901	1.54
   testCompareUGEMaskNotLong	ops/s	2088357.736	71696.24791	2973202.26	63278.78974	1.42
   testCompareUGEMaskNotShort	ops/s	8348624.02	116562.7876	12832250.78	546869.3006	1.53
   testCompareUGTMaskNotByte	ops/s	17871101.25	800199.6321	19902619.81	214003.3262	1.11
   testCompareUGTMaskNotInt	ops/s	4088304.421	137797.9723	7135454.33	124553.651	1.74
   testCompareUGTMaskNotLong	ops/s	2070610.42	19881.82182	2991536.365	36260.60767	1.44
   testCompareUGTMaskNotShort	ops/s	8637099.341	155822.1608	12756579.77	186068.199	1.47
   testCompareULEMaskNotByte	ops/s	17940901.36	1258029.364	18932484.94	694554.6305	1.05
   testCompareULEMaskNotInt	ops/s	4369177.511	74982.31936	6392773.082	550171.2266	1.46
   testCompareULEMaskNotLong	ops/s	2135905.761	43693.63178	2877579.631	41651.56289	1.34
   testCompareULEMaskNotShort	ops/s	8607710.544	132655.1676	12446370.04	441718.3035	1.44
   testCompareULTMaskNotByte	ops/s	17409912.23	1033204.537	20607479.99	362000.5056	1.18
   testCompareULTMaskNotInt	ops/s	4386455.9	119192.1635	6920123.264	186158.2845	1.57
   testCompareULTMaskNotLong	ops/s	2064995.149	38622.2734	2988343.589	39037.90006	1.44
   testCompareULTMaskNotShort	ops/s	8642182.752	230919.2442	13029582.09	437101.4923	1.5
   ```
   
   The small amount of performance degradation is due to test fluctuations.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24674/files
  - new: https://git.openjdk.org/jdk/pull/24674/files/1b9c3b36..34eae981

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=01-02

  Stats: 36244 lines in 1018 files changed: 28133 ins; 5853 del; 2258 mod
  Patch: https://git.openjdk.org/jdk/pull/24674.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24674/head:pull/24674

PR: https://git.openjdk.org/jdk/pull/24674

From duke at openjdk.org  Fri Apr 25 07:31:59 2025
From: duke at openjdk.org (erifan)
Date: Fri, 25 Apr 2025 07:31:59 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v2]
In-Reply-To: <46g4wcnZe1Hiodlu9pe4VOoE6hzpKz5tousDFKzs8qA=.edca6b56-d299-41de-a714-4f5ad5bdaa6d@github.com>
References: 
 
 <46g4wcnZe1Hiodlu9pe4VOoE6hzpKz5tousDFKzs8qA=.edca6b56-d299-41de-a714-4f5ad5bdaa6d@github.com>
Message-ID: 

On Thu, 24 Apr 2025 10:28:15 GMT, Andrew Haley  wrote:

>> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8354242
>>  - 8354242: VectorAPI: combine vector not operation with compare
>>    
>>    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	...
>
> src/hotspot/share/opto/node.cpp line 1226:
> 
>> 1224:     // be added to the IGVN worklist, then the optimization will not be applied.
>> 1225:     // Therefore, add this node into IGVN worklist to make the optimization happen.
>> 1226:     return true;
> 
> Suggestion:
> 
>   } else if (n->Opcode() == Op_XorV || n->Opcode() == Op_XorVMask) {
>     // Condition for removing an unnecessary not() following
>     // a compare(...) operation.
>     // The predecessor of n (this XorV or XorVMask) may also be used
>     // by a useless VectorBox node which will later be eliminated by
>     // RemoveUseless. Return true to ensure that subgraph
>     // transformations are performed on n.
>     return true;

Done. Thanks for your review.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2059706930

From duke at openjdk.org  Fri Apr 25 07:32:01 2025
From: duke at openjdk.org (erifan)
Date: Fri, 25 Apr 2025 07:32:01 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 24 Apr 2025 09:39:58 GMT, erifan  wrote:

>> src/hotspot/share/opto/vectornode.cpp line 2265:
>> 
>>> 2263:     vmcmp = new VectorMaskCastNode(phase->transform(vmcmp), vmcast_vt);
>>> 2264:   }
>>> 2265:   return vmcmp;
>> 
>> It would be preferable if you could kindly re-factor the code such that we only call VectorNode::Ideal once at return to comply with aesthetics of other idealization routines.
>
> Ok, I'll change it in the next commit.

Done, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2059702378

From serb at openjdk.org  Fri Apr 25 07:44:11 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 25 Apr 2025 07:44:11 GMT
Subject: RFR: 8346610: Make all imports consistent in the FFM API [v3]
In-Reply-To: 
References: 
 
Message-ID: <_78CpnndEgiZMuR_2Or27GaOoT_2ZmRljaL6Hzn0JnM=.d6a31947-306b-4799-a627-5027220a84ae@github.com>

On Thu, 9 Jan 2025 11:47:15 GMT, Per Minborg  wrote:

>> This PR proposes to clean up all the imports in the FFM lib (excluding tests).
>> 
>> Passes tier1-tier3
>
> Per Minborg 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 fix-imports
>  - Update copyright year and reformat
>  - Merge branch 'master' into fix-imports
>  - Fix imports

src/java.base/share/classes/jdk/internal/foreign/abi/DowncallLinker.java line 46:

> 44: import java.util.stream.Stream;
> 45: 
> 46: import static java.lang.invoke.MethodHandles.*;

It looks inconsistent that in some places you remove the wildcard (*) imports, while in others you add them.

By the way, where does this convention come from? I believe most of the codebase follows the import order: java ? empty line ? javax ? empty line ? other jdk packages in alphabetical order ? empty line ? repeat the same groups for static imports.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22827#discussion_r2059725341

From serb at openjdk.org  Fri Apr 25 07:44:57 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 25 Apr 2025 07:44:57 GMT
Subject: RFR: 8347814: Make all imports consistent in the FFM API tests and
 benchmarks
In-Reply-To: <5KNH2AAZ_KnLt2xRMfHFFNmJ8zf0p6n-arS-XSq5jm8=.3b36aafe-b403-4bf4-89e3-548829d46673@github.com>
References: <5KNH2AAZ_KnLt2xRMfHFFNmJ8zf0p6n-arS-XSq5jm8=.3b36aafe-b403-4bf4-89e3-548829d46673@github.com>
Message-ID: <22hdJ4cH7IyMcuOwUldde-fCYYxPFVxtVCTQlBHu0U8=.69ff86b5-c075-41b9-9cd5-1502ce3b584c@github.com>

On Wed, 19 Feb 2025 09:22:09 GMT, Per Minborg  wrote:

> This PR proposes to make all imports consistent in the FFM API tests and benchmarks.
> 
> This is a follow-up PR from https://github.com/openjdk/jdk/pull/22827
> 
> Passes tier1-3

test/jdk/java/foreign/TestFunctionDescriptor.java line 38:

> 36: import java.util.Optional;
> 37: 
> 38: import static org.testng.Assert.*;

Duplicate my comment: https://github.com/openjdk/jdk/pull/22827/files#r2059725341

It looks inconsistent that in some places you remove the wildcard (*) imports, while in others you add them.

By the way, where does this convention come from? I believe most of the codebase follows the import order: java ? empty line ? javax ? empty line ? other jdk packages in alphabetical order ? empty line ? repeat the same groups for static imports.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23689#discussion_r2059729379

From duke at openjdk.org  Fri Apr 25 07:57:03 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Fri, 25 Apr 2025 07:57:03 GMT
Subject: RFR: 8355301: Simplify Throwable::printStackTrace by using record
 [v4]
In-Reply-To: 
References: 
 <2FArm3JRh9gez7hXK0J3YS8U5tgVTCGxdd0y1qq1cLw=.9593786d-27dd-4bd7-819d-1cd4c125d0bd@github.com>
 
 
 
 
Message-ID: 

On Fri, 25 Apr 2025 07:06:05 GMT, Alan Bateman  wrote:

>>> What should we replace it with? Do you have any suggestions?
>> 
>> The wrapper classes were needed when there were was a mix of synchronized and j.u.concurrent locks in use. With JEP 491 integrated it meant that the java.io classes could be changed back to use synchronized.  Yes, we could do some cleanup in Throwable too. Changing PrintStreamOrWriter to be an interface should be fine but the rest of these changes in this PR doesn't seem necessary. As others have already asked, I think it would be useful to understand what issue you are running into and why you want to change this code.
>
>> @AlanBateman I have modified it to use interface + record. Is this what you want?
> 
> I don't object to changing it to interface + record but it feels more like needless code churn. I really disliked the next version that used printStackTrace0(Object printer) as it immediately invites another re-write.

The record has fewer source lines but doesn't the generated record class have a getter, toString(), hashCode() and equals(Object) which are not needed here?
What about using a lock parameter and a method handle to pass in the required features of PrintStream and PrintWriter:

public void printStackTrace(PrintWriter pw) {
    printStackTrace(pw, pw::println);
}

public void printStackTrace(PrintStream ps) {
    printStackTrace(ps, ps::println);
}

private void printStackTrace(Object lock, Consumer println) {
    synchronized(lock) {
    	...
        println.accept(this);
    	...
    }
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24795#discussion_r2059745913

From eirbjo at openjdk.org  Fri Apr 25 08:00:59 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 25 Apr 2025 08:00:59 GMT
Subject: RFR: 8355301: Simplify Throwable::printStackTrace by using record
 [v5]
In-Reply-To: <07nJuCtiCHpwz95wfQKqTC8fXuqB-8hn-wEtESimz2c=.d18e8d12-0155-46ee-a7c5-eb40ae1bb460@github.com>
References: 
 <07nJuCtiCHpwz95wfQKqTC8fXuqB-8hn-wEtESimz2c=.d18e8d12-0155-46ee-a7c5-eb40ae1bb460@github.com>
Message-ID: 

On Thu, 24 Apr 2025 17:36:29 GMT, Shaojin Wen  wrote:

>> The current Throwable::printStackTrace implementation uses three inner classes PrintStreamOrWriter/WrappedPrintStream/WrappedPrintWriter. We can introduce a static method println to replace these three embedded classes.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use interface + record

This PR seems like a solution in search of a problem, the goalpost seems to be moving and the communication hasn't been great.

The existing wrapper classes are just that - wrapper classes. They don't really hold data, their components aren't used as data, they have no hashCode / equals. As such, these internal implementation classes do not look like prime targets to convert to records to me. If we really want to change every class to be a record there will be a lot of code churn for no good reason. Are classes toxic legacy now?

@liach suggested to remove the wrapper classes and instead use a static method with `instanceof` checking. That would remove the need for both the interface and the wrapper classes which seems like a real improvement. @AlanBateman seems to have been reluctant to such a change, but I don't think I (or others in this PR) quite understood his reasoning for that opposition.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24795#issuecomment-2829657158

From sgehwolf at openjdk.org  Fri Apr 25 08:23:56 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 25 Apr 2025 08:23:56 GMT
Subject: Integrated: 8355524: Only every second line in upgradeable files is
 being used
In-Reply-To: 
References: 
Message-ID: <124v10XAO1D57mtV9sNXTmiemTvOJGtEIbyrSXj924Y=.f8181f73-0bab-463d-8200-9a051350b9d6@github.com>

On Thu, 24 Apr 2025 17:31:50 GMT, Severin Gehwolf  wrote:

> Please review this fix to [JDK-8353185](https://bugs.openjdk.org/browse/JDK-8353185). The reading logic for the config file would erroneously use `scanner.nextLine()` when the current line to be added is in `line`. `line` is not being added, but `scanner.nextLine()` unintentionally skipping lines. The config file has a change too. It moves the `tzdb.dat` line last so that the existing test verifies that the `cacerts` one isn't being skipped. This slipped through because `tzdb.dat` updates aren't automatically tested.
> 
> Testing:
> - [x] GHA
> - [x] The test from [JDK-8353185](https://bugs.openjdk.org/browse/JDK-8353185), `UpgradeableFileCacertsTest.java` fails with the config file change only (without the product fix) and passes with the one-liner. Also some manual testing when both files have been upgraded.
> 
> Thoughts?

This pull request has now been integrated.

Changeset: 89f9268e
Author:    Severin Gehwolf 
URL:       https://git.openjdk.org/jdk/commit/89f9268ed7c2cb86891f23a10482cd459454bd32
Stats:     3 lines in 2 files changed: 1 ins; 1 del; 1 mod

8355524: Only every second line in upgradeable files is being used

Reviewed-by: shade, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/24855

From sgehwolf at openjdk.org  Fri Apr 25 08:23:55 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 25 Apr 2025 08:23:55 GMT
Subject: RFR: 8355524: Only every second line in upgradeable files is being
 used
In-Reply-To: 
References: 
Message-ID: 

On Thu, 24 Apr 2025 17:31:50 GMT, Severin Gehwolf  wrote:

> Please review this fix to [JDK-8353185](https://bugs.openjdk.org/browse/JDK-8353185). The reading logic for the config file would erroneously use `scanner.nextLine()` when the current line to be added is in `line`. `line` is not being added, but `scanner.nextLine()` unintentionally skipping lines. The config file has a change too. It moves the `tzdb.dat` line last so that the existing test verifies that the `cacerts` one isn't being skipped. This slipped through because `tzdb.dat` updates aren't automatically tested.
> 
> Testing:
> - [x] GHA
> - [x] The test from [JDK-8353185](https://bugs.openjdk.org/browse/JDK-8353185), `UpgradeableFileCacertsTest.java` fails with the config file change only (without the product fix) and passes with the one-liner. Also some manual testing when both files have been upgraded.
> 
> Thoughts?

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24855#issuecomment-2829707368

From alanb at openjdk.org  Fri Apr 25 08:25:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Apr 2025 08:25:50 GMT
Subject: RFR: 8355301: Simplify Throwable::printStackTrace by using record
 [v5]
In-Reply-To: 
References: 
 <07nJuCtiCHpwz95wfQKqTC8fXuqB-8hn-wEtESimz2c=.d18e8d12-0155-46ee-a7c5-eb40ae1bb460@github.com>
 
Message-ID: <9MnIYRjRS8hmXbhxZK15ECddpN9qq9lTSzuUfLY_gsE=.057ebe4b-038b-4d04-b29c-cb423c57d5d6@github.com>

On Fri, 25 Apr 2025 07:57:53 GMT, Eirik Bj?rsn?s  wrote:

> @liach suggested to remove the wrapper classes and instead use a static method with `instanceof` checking. That would remove the need for both the interface and the wrapper classes which seems like a real improvement. @AlanBateman seems to have been reluctant to such a change, but I don't think I (or others in this PR) quite understood his reasoning for that opposition.

I commented on the iteration that introduced printStackTrace0(Object printer) as it was just begging to be replaced again. Johannes D?bler's suggestion avoids that. There are probably 100 others ways it could be written.

As others have noted, the motivation for the JBS issue and PR isn't very clear. There are many large features and changes in progress right now, I think better for potential Reviewers to focus on helping those rather than on churn code in core classes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24795#issuecomment-2829716111

From alanb at openjdk.org  Fri Apr 25 08:58:19 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Apr 2025 08:58:19 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Thu, 3 Apr 2025 01:19:18 GMT, Chen Liang  wrote:

>> Seconded
>
> I personally think this is more of an implementation artifact for `StableValue::supplier` and doesn't merit its own API (as no other StableValue API utilizes the object monitor of a StableValue), but maybe we can adjust this in a later preview...

I think "throws an exception" is really exception and error. I'm not suggesting this has to be changed now but if you are re-visiting this paragraph then this could be made a bit clearer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2059841557

From pminborg at openjdk.org  Fri Apr 25 09:15:30 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 25 Apr 2025 09:15:30 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v78]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 24 Apr 2025 13:35:45 GMT, Luca Kellermann  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make public constuctor private
>
> src/java.base/share/classes/java/lang/StableValue.java line 389:
> 
>> 387:  * Invocations of {@link #setOrThrow(Object)} form a total order of zero or more
>> 388:  * exceptional invocations followed by zero (if the contents were already set) or one
>> 389:  * successful invocation. Since stable functions and stable collections are built on top
> 
> How can an exceptional invocation of `setOrThrow` be followed by a successful invocation?

`setOrThrow` might be invoked several times. If the first invocation failed because the supplier threw and then the second invocation (with the same supplier) succeded (because there was some state that changed), we have this situation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2059866634

From jbhateja at openjdk.org  Fri Apr 25 09:20:05 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 25 Apr 2025 09:20:05 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: <7IGU54ppPKoebXOt0BaS9r-eYf92mtILbHLu8RsfmSk=.a0b3259c-e5ea-43a2-b34c-38d439bd0a41@github.com>

On Thu, 24 Apr 2025 09:37:07 GMT, erifan  wrote:

>> src/hotspot/share/opto/vectornode.cpp line 2243:
>> 
>>> 2241:     in1 = in1->in(1);
>>> 2242:   }
>>> 2243:   if (in1->Opcode() != Op_VectorMaskCmp || in1->outcnt() > 1 ||
>> 
>> Checks on outcnt on line 2243 and 2238 can be removed. Idealization looks for a specific graph palette and replaces it with a new node whose inputs are the same as the inputs of the palette. GVN will do the retention job if any intermediate node has users beyond the pattern being replaced.
>
> Thanks for telling me this information. Another more important reason to check outcnt here is to prevent this optimization when the uses of VectorMaskCmp is greater than 1, because this optimization may not be worthwhile. For example:
> 
> 
>   public static void testVectorMaskCmp() {
>     IntVector bv = IntVector.fromArray(I_SPECIES, ib, 0);
>     IntVector av = IntVector.fromArray(I_SPECIES, ia, 0);
>     VectorMask m1 = av.compare(VectorOperators.NE, bv);  // two uses
>     VectorMask m2 =m1.not();
>     m1.intoArray(m, 0);
>     av.lanewise(VectorOperators.ABS, m2).intoArray(ia, 0);
>   }
> 
> 
> If we do not check outcnt and still do this optimization, two VectorMaskCmp nodes will be generated, and finally two VectorMaskCmp instructions will be generated. This is unreasonable because VectorMaskCmp has much higher latency than xor instruction on aarch64.

Thanks, we can add this comment to the code where we are checking outcnt. What if all the other users are also XorNodes?.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2059874975

From duke at openjdk.org  Fri Apr 25 09:20:15 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Fri, 25 Apr 2025 09:20:15 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v78]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 25 Apr 2025 09:11:43 GMT, Per Minborg  wrote:

>> src/java.base/share/classes/java/lang/StableValue.java line 389:
>> 
>>> 387:  * Invocations of {@link #setOrThrow(Object)} form a total order of zero or more
>>> 388:  * exceptional invocations followed by zero (if the contents were already set) or one
>>> 389:  * successful invocation. Since stable functions and stable collections are built on top
>> 
>> How can an exceptional invocation of `setOrThrow` be followed by a successful invocation?
>
> `setOrThrow` might be invoked several times. If the first invocation failed because the supplier threw and then the second invocation (with the same supplier) succeded (because there was some state that changed), we have this situation.

`orElseSet` is the method taking a supplier, `setOrThrow` doesn't.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2059875280

From pminborg at openjdk.org  Fri Apr 25 09:24:47 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 25 Apr 2025 09:24:47 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v78]
In-Reply-To: 
References: 
 
 
Message-ID: <7iynb2QDGoAeW09HHh7b4rmv1Bt1Q_3OZhEcyvG_-OM=.3657b101-f35c-43f5-8a68-02ec3e8ba38f@github.com>

On Fri, 25 Apr 2025 06:28:59 GMT, Alan Bateman  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make public constuctor private
>
> src/java.base/share/classes/java/lang/StableValue.java line 470:
> 
>> 468:      * @param other to return if the contents is not set
>> 469:      */
>> 470:     T orElse(T other);
> 
> Just to note that JEP 506 is proposing to change ScopedValue.orElse to disallow null. A ScopedValue can be bound to null (e.g. usage in Subject API) so using orElse(null) is problematic. A orNull may be added later if needed. As a StableValue can hold null then it's similar and might be surprising to developers to have the two APIs be different here. Something to look at again after JEP 502 is integrated, I'm not suggesting changing anything in this PR of course.

Yepp. Disallowing `null` is on the list for exploring in the next preview.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2059881042

From jbhateja at openjdk.org  Fri Apr 25 09:44:04 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 25 Apr 2025 09:44:04 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v13]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 24 Apr 2025 23:03:09 GMT, Vladimir Ivanov  wrote:

>> src/hotspot/share/opto/vectorIntrinsics.cpp line 563:
>> 
>>> 561:     debug_name = debug_name_oop->const_oop()->as_instance()->java_lang_String_str(buf, buflen);
>>> 562:   }
>>> 563:   Node* vcall = make_runtime_call(RC_VECTOR,
>> 
>> By generating an upfront CallLeafVectorNode, we may miss out on performing any GVN-style optimization for trigonometric identities like the following. do you think creating a macro node which can lazily be expanded to call node during macro expansion will help.
>> 
>> arcsin(sin(x)) => x
>> arccos(cos(x)) => x
>> sin(arcsin(x) => x
>> cos(arccos(x) => x
>
> It does look attractive, but macro expansion-based solution requires JVM to internalize such operations and their properties. 
> 
> IMO a higher-level solution based on more generic JVM primitives would enable libraries to properly annotate their operations in Java bytecodes/class files, so C2 can perform such type of transformations without the need to intrinsify each individual operation first. (Think of [JDK-8218414](https://bugs.openjdk.org/browse/JDK-8218414) / [JDK-8347901](https://bugs.openjdk.org/browse/JDK-8347901) on steroids.)

I agree, this is a typical graph transform which cannot be applied currently because we are generating CallLeafVectorNode upfront during parsing, If we prevent intrinsification then compiler will attempt inlining, generating a much complex graph shape which may not be reducible.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2059911738

From jbhateja at openjdk.org  Fri Apr 25 09:53:53 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 25 Apr 2025 09:53:53 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 24 Apr 2025 08:57:14 GMT, erifan  wrote:

>> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8354242
>>  - 8354242: VectorAPI: combine vector not operation with compare
>>    
>>    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	...
>
> src/hotspot/share/opto/vectornode.cpp line 2234:
> 
>> 2232:   // XorV/XorVMask is commutative, swap VectorMaskCmp/Op_VectorMaskCast to in1.
>> 2233:   if (in1->Opcode() != Op_VectorMaskCmp && in1->Opcode() != Op_VectorMaskCast) {
>> 2234:     swap(in1, in2);
> 
> The edges are not swapped, but two variables in1 and in2

My bad.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2059881507

From jbhateja at openjdk.org  Fri Apr 25 09:53:54 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 25 Apr 2025 09:53:54 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 24 Apr 2025 09:46:24 GMT, erifan  wrote:

>> test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java line 38:
>> 
>>> 36:  * @summary test combining vector not operation with compare
>>> 37:  * @modules jdk.incubator.vector
>>> 38:  * @requires ((os.arch!="x86" & os.arch!="i386" & os.arch!="amd64" & os.arch!="x86_64") | vm.cpu.features ~= ".*avx.*")
>> 
>> You can remove this platform limitation and forward the constraints to @IR rules using applyIfCPUFeatureOr
>
> Since this is a platform independent optimization, I tend to use this `@requires` because it's simpler.  If we use `applyIfCPUFeatureOr`, we need to add the same restriction before each test. In addition, if a new architecture supports the vector node, this test may not cover it. What do you think?

I don't see XorVMask implemented on all non-x86 target, like PPC etc..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2059923958

From duke at openjdk.org  Fri Apr 25 10:03:33 2025
From: duke at openjdk.org (Gautham Krishnan)
Date: Fri, 25 Apr 2025 10:03:33 GMT
Subject: RFR: 8342886: Update MET timezone in TimeZoneNames files
Message-ID: 

MET timezone entry in TimeZoneNames.java and TimeZoneNames_*.java needs to be updated as MET is alias to Europe/Brussels as per 2024b tzdata changes.

Also Bug4848242.java needs to be removed as the test expects all euro locale time zones should have the same short names.

-------------

Commit messages:
 - Update MET timezone in TimeZoneNames files

Changes: https://git.openjdk.org/jdk/pull/24871/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24871&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342886
  Stats: 112 lines in 12 files changed: 0 ins; 90 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/24871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24871/head:pull/24871

PR: https://git.openjdk.org/jdk/pull/24871

From msheppar at openjdk.org  Fri Apr 25 10:21:01 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Fri, 25 Apr 2025 10:21:01 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value
In-Reply-To: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
Message-ID: 

On Thu, 24 Apr 2025 20:46:42 GMT, Brian Burkhalter  wrote:

> Use the `@requires` tag instead of obtaining the operating system name from the `os.name` property and then exiting if the test is not run on that operating system.

a general comment on this approach of running tests selectively on an OS via @requires
It is all cool and dandy, but this has implications on the visibility of the test not being run. 
It will be added to the jtreg "not run" list
When running test locally that's fine, this is easily seen in the jtreg report, but when run in the test frameworks CI pipeline, this "not run " visibility is obscured. Thus when doing test run audit of a jobs, requires a bit more effort to locate test that have not been run.

An alternative practice has been to throw a SkippedException and this is more easily observed in a pipeline job's results, as the SkippedException are part of all results, and jtreg now reports Skipped tests in its summary

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24860#issuecomment-2830009985

From msheppar at openjdk.org  Fri Apr 25 10:27:55 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Fri, 25 Apr 2025 10:27:55 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value
In-Reply-To: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
Message-ID: 

On Thu, 24 Apr 2025 20:46:42 GMT, Brian Burkhalter  wrote:

> Use the `@requires` tag instead of obtaining the operating system name from the `os.name` property and then exiting if the test is not run on that operating system.

test/jdk/java/io/File/MacPathTest.java
test/jdk/java/io/File/MaxPath.java

maybe for these two cases, throw a SkippedException rather than just return ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24860#issuecomment-2830026232

From alanb at openjdk.org  Fri Apr 25 10:41:19 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Apr 2025 10:41:19 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v78]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 24 Apr 2025 10:37:59 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make public constuctor private

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 175:

> 173:     private void preventReentry() {
> 174:         if (Thread.holdsLock(this)) {
> 175:             throw new IllegalStateException("Recursive initialization of a stable value is illegal");

I don't know how common it is to use holdsLocks for control flow but just to say that there are several places in the JDK that have to detect reentrancy and some of these are good candidates to use ScopedValues.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2059996394

From alanb at openjdk.org  Fri Apr 25 10:46:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Apr 2025 10:46:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v78]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 24 Apr 2025 10:37:59 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make public constuctor private

I've been through the API + implementation, and a brief scan (not detailed) of the tests. Good job, it will be good to get this integrated and start to get some usage and feedback.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23972#pullrequestreview-2793718267

From jpai at openjdk.org  Fri Apr 25 11:34:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Apr 2025 11:34:57 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
References: 
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
Message-ID: 

On Wed, 23 Apr 2025 00:56:18 GMT, Jiangli Zhou  wrote:

>> Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
>> 
>> `NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.
>> 
>> In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
>  - Address henryjen@ comment:
>    - Remove '#include '.

Hello Jiangli, if I understand this change correctly, then this is forcing a non-JNI library to be a JNI library for it to work on static JDK. Is that a requirement for static JDK builds? Or is it just a convenient way to use existing library loading mechanism in the `jdk.internal.loader.NativeLibraries`?

Are there other similar libraries shipped in JAVA_HOME/lib that would require a similar change/treatment?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2830165959

From pminborg at openjdk.org  Fri Apr 25 13:17:06 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 25 Apr 2025 13:17:06 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Tue, 25 Mar 2025 14:20:24 GMT, Luca Kellermann  wrote:

>>> Comments on visual noise and side effects in `toString`.
>>> 
>>> `renderWrapped` is clever for a single stable value, but it makes for a very noisy display string, with confusing doubly-nested `[]`, for composite stable values. I'm talking about `StableFunction` mainly, I guess.
>>> 
>>> I suggest omitting the inner `[]` for such composites. A simple boolean on `renderWrapped` will do that trick. In that case, `renderWrapped` has the job of either presenting a fixed (recognizable) sentinel string, or else forwards, without further editorial comment, to the `toString` of the contained value.
>> 
>> The `toString()` for `StableValue` is inspired by `Optional` which works in the same way by adding `[ ]` around the contents. Any more thought in the reviewer community on how we should handle this?
>
>> > Comments on visual noise and side effects in `toString`.
>> > `renderWrapped` is clever for a single stable value, but it makes for a very noisy display string, with confusing doubly-nested `[]`, for composite stable values. I'm talking about `StableFunction` mainly, I guess.
>> > I suggest omitting the inner `[]` for such composites. A simple boolean on `renderWrapped` will do that trick. In that case, `renderWrapped` has the job of either presenting a fixed (recognizable) sentinel string, or else forwards, without further editorial comment, to the `toString` of the contained value.
>> 
>> The `toString()` for `StableValue` is inspired by `Optional` which works in the same way by adding `[ ]` around the contents. Any more thought in the reviewer community on how we should handle this?
> 
> I think the comment just proposes that this code
> 
> var f = StableValue.intFunction(3, i -> i);
> f.apply(1);
> System.out.println(f);
> 
> should print
> 
> StableIntFunction[values=[.unset, 1, .unset], original=...]
> 
> Right now it prints this:
> 
> StableIntFunction[values=[.unset, [1], .unset], original=...]
> 
> The `toString` implementation for `StableValueImpl` itself seems fine.

Thank you, @lukellmann, for your comments. Some of them were very useful! I will address them _after_ integrating the PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2830400309

From alanb at openjdk.org  Fri Apr 25 13:51:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Apr 2025 13:51:48 GMT
Subject: RFR: 8354450: Using a File with a path containing a trailing space
 should fail when alternative data streams are disabled (win) [v2]
In-Reply-To: 
References: <8nRvvYmACuUpIsMfmwgjDMwBzXyFkjLKNwINeSLN-LI=.67524f3d-74ad-4b6d-bb8f-6f30ea958566@github.com>
 
 <1EKMYPzdR0EfG8v9_hauG3wPMw0_cRATLZlg0LbE4ps=.049a55bc-797a-4eb4-9b4a-f20b02cafbe4@github.com>
 
 <7LDV_FtSki03-PTPsSoobe3N-SbtcjVKzf933HBuFoQ=.474914b7-beda-4f80-8655-c0523bd23a87@github.com>
 
 
 
Message-ID: 

On Fri, 18 Apr 2025 18:22:35 GMT, Brian Burkhalter  wrote:

>>> From experimentation with C++ code is VS, it appears that `CreateDirectoryW` will create a directory with either a leading or trailing space in its name, whereas `createFileW` will create a file with a leading space in its name, but a trailing space is trimmed.
>> 
>> Right, the Windows APIs are very inconsistent on this, and why the Windows implementation of Path will always reject input where an element has a trailing space.
>
> It turns out that a case such as `foo \bar\gus` already fails in `File.mkdirs` due to directory creation itself, so an explicit check for a trailing space in directory elements does not appear to be necessary, although having the failure occur in `isInvalid` would be more fail-fast.

The benefit of doing it before attempting any I/O operation is avoids the unpredictable behavior of the Win32 calls. Otherwise, I think it means through each Win32 call used by WinNTFileSystem and seeing how it behaves.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24635#discussion_r2060283293

From alanb at openjdk.org  Fri Apr 25 14:07:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Apr 2025 14:07:57 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 23 Mar 2025 09:28:38 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.
>> 
>> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.
>> 
>> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.
>> 
>> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta...
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - improve code comment for ZipFile.zipCoder
>  - Alan's suggestion - change code comment about Source class being thread safe
>  - Alan's suggestion - trim the javadoc of (internal) ZipCoder class

I did a pass over the latest (4e3f8e70) and it looks quite good. I'll do another read over it early next week as I think it would be good to get this fixed well in advance of RDP1.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23986#issuecomment-2830534278

From liach at openjdk.org  Fri Apr 25 14:24:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 25 Apr 2025 14:24:50 GMT
Subject: RFR: 8355301: Simplify Throwable::printStackTrace by using record
 [v4]
In-Reply-To: 
References: 
 <2FArm3JRh9gez7hXK0J3YS8U5tgVTCGxdd0y1qq1cLw=.9593786d-27dd-4bd7-819d-1cd4c125d0bd@github.com>
 
 
 
 
 
Message-ID: 

On Fri, 25 Apr 2025 07:54:03 GMT, Johannes D?bler  wrote:

>>> @AlanBateman I have modified it to use interface + record. Is this what you want?
>> 
>> I don't object to changing it to interface + record but it feels more like needless code churn. I really disliked the next version that used printStackTrace0(Object printer) as it immediately invites another re-write.
>
> The record has fewer source lines but doesn't the generated record class have a getter, toString(), hashCode() and equals(Object) which are not needed here?
> What about using a lock parameter and a method handle to pass in the required features of PrintStream and PrintWriter:
> 
> public void printStackTrace(PrintWriter pw) {
>     printStackTrace(pw, pw::println);
> }
> 
> public void printStackTrace(PrintStream ps) {
>     printStackTrace(ps, ps::println);
> }
> 
> private void printStackTrace(Object lock, Consumer println) {
>     synchronized(lock) {
>     	...
>         println.accept(this);
>     	...
>     }
> }

FYI lambda expressions depend on java.lang.invoke, and if anything initialized before that throws an exception and needs to print stack trace, the VM will fail with a traceless `StackOverflowError` I think. Consumer class is fine for early loading, but  to implement that, we fall back to records again.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24795#discussion_r2060345723

From michaelm at openjdk.org  Fri Apr 25 14:26:43 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 25 Apr 2025 14:26:43 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v8]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge branch 'master' into 8348986-exceptions
 - Review update
 - review update
 - Merge branch 'master' into 8348986-exceptions
 - update to minimise code changes
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Apply suggestions from code review
   
   from turbanoff review
   
   Co-authored-by: Andrey Turbanov 
 - doc + copyright update
 - remove file added by mistake
 - ... and 12 more: https://git.openjdk.org/jdk/compare/5c067232...9401d4c8

-------------

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=07
  Stats: 949 lines in 42 files changed: 716 ins; 101 del; 132 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From jpai at openjdk.org  Fri Apr 25 14:27:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Apr 2025 14:27:55 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 23 Mar 2025 09:28:38 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.
>> 
>> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.
>> 
>> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.
>> 
>> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta...
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - improve code comment for ZipFile.zipCoder
>  - Alan's suggestion - change code comment about Source class being thread safe
>  - Alan's suggestion - trim the javadoc of (internal) ZipCoder class

Thank you Alan, Eirik and others for the review comments so far. There's one review comment from Eirik which I plan to respond and update this PR with. I got involved with something else and couldn't focus on this PR the past few weeks. I plan to refresh this in the coming few days and have it ready well in advance of RDP1 of 25.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23986#issuecomment-2830582779

From swen at openjdk.org  Fri Apr 25 14:38:46 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 25 Apr 2025 14:38:46 GMT
Subject: RFR: 8355301: Simplify Throwable::printStackTrace by using record
 [v5]
In-Reply-To: <07nJuCtiCHpwz95wfQKqTC8fXuqB-8hn-wEtESimz2c=.d18e8d12-0155-46ee-a7c5-eb40ae1bb460@github.com>
References: 
 <07nJuCtiCHpwz95wfQKqTC8fXuqB-8hn-wEtESimz2c=.d18e8d12-0155-46ee-a7c5-eb40ae1bb460@github.com>
Message-ID: 

On Thu, 24 Apr 2025 17:36:29 GMT, Shaojin Wen  wrote:

>> The current Throwable::printStackTrace implementation uses three inner classes PrintStreamOrWriter/WrappedPrintStream/WrappedPrintWriter. We can introduce a static method println to replace these three embedded classes.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use interface + record

As discussed above, more than one developer has expressed opposition to this change, and the benefits are not obvious. I plan to close it. I am sorry to take up your time for review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24795#issuecomment-2830615786

From liach at openjdk.org  Fri Apr 25 14:49:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 25 Apr 2025 14:49:12 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v78]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 24 Apr 2025 10:37:59 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make public constuctor private

I think the design and the essential implementation meets the "95% complete" bar for preview features. There are some ceremony like toString and some other details like null values, but they should not be serious enough for this to be delivered for preview.

src/java.base/share/classes/java/util/ImmutableCollections.java line 1585:

> 1583: 
> 1584:         @jdk.internal.ValueBased
> 1585:         final class StableMapEntrySet extends AbstractImmutableSet> {

One concern about the (non-static) inner classes is that we can't stable-annotate the immediately enclosing instance - we might need general trusting for java.util, but we need to ensure users aren't hacking collection final fields first.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23972#pullrequestreview-2794371078
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2060378300

From liach at openjdk.org  Fri Apr 25 14:52:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 25 Apr 2025 14:52:54 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 23 Mar 2025 09:28:38 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.
>> 
>> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.
>> 
>> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.
>> 
>> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta...
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - improve code comment for ZipFile.zipCoder
>  - Alan's suggestion - change code comment about Source class being thread safe
>  - Alan's suggestion - trim the javadoc of (internal) ZipCoder class

Thanks, I think our only requests were for comment updates to ease maintenance down the road, as the original issue was caused by incorrect assumptions that ZipCoder is stateless. The code itself looks robust already.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23986#issuecomment-2830651069

From asotona at openjdk.org  Fri Apr 25 14:56:48 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 25 Apr 2025 14:56:48 GMT
Subject: RFR: 8354877: DirectClassBuilder default flags should include
 ACC_SUPER
In-Reply-To: <0ranEoj50aTeRbxcIKrpenUwkjCFQdkRzixtS7CvFiY=.56a42ff8-bd0c-471b-9779-606a804391b9@github.com>
References: <0ranEoj50aTeRbxcIKrpenUwkjCFQdkRzixtS7CvFiY=.56a42ff8-bd0c-471b-9779-606a804391b9@github.com>
Message-ID: <92OFcxtzdtx6Qv3x7OFzdTfMTEBj9lQ35QopK_NIyRw=.c75c47fe-06d8-4be5-a49a-083821b295c1@github.com>

On Tue, 22 Apr 2025 23:55:54 GMT, Chen Liang  wrote:

> In the future value objects JEP, class files must have one of ACC_IDENTITY (now ACC_SUPER), ACC_ABSTRACT, and ACC_FINAL bits set, otherwise they are rejected. The current default flag has none of these bits set, meaning that it will not be suitable in the future. Currently, most class file generation in the JDK explicitly set ACC_SUPER for compatibility; we should also set this bit in the default flags, despite being no-op, in anticipation of future compatibility.
> 
> The API specifications of ClassBuilder and AccessFlags already state that an unspecified default flag for class builders are chosen, so changing this flag should be fine without extra specification changes.

I don't think the potential bitmask match between proposed ACC_IDENTITY flag and currently obsolete ACC_SUPER flag is good reason to set it as default now. It may cause even more confusion and may be even conflicts.
Are there any use cases where current mainline Class-File API should produce future class version with default flags?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24808#issuecomment-2830661522

From liach at openjdk.org  Fri Apr 25 15:03:45 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 25 Apr 2025 15:03:45 GMT
Subject: RFR: 8354877: DirectClassBuilder default flags should include
 ACC_SUPER
In-Reply-To: <0ranEoj50aTeRbxcIKrpenUwkjCFQdkRzixtS7CvFiY=.56a42ff8-bd0c-471b-9779-606a804391b9@github.com>
References: <0ranEoj50aTeRbxcIKrpenUwkjCFQdkRzixtS7CvFiY=.56a42ff8-bd0c-471b-9779-606a804391b9@github.com>
Message-ID: 

On Tue, 22 Apr 2025 23:55:54 GMT, Chen Liang  wrote:

> In the future value objects JEP, class files must have one of ACC_IDENTITY (now ACC_SUPER), ACC_ABSTRACT, and ACC_FINAL bits set, otherwise they are rejected. The current default flag has none of these bits set, meaning that it will not be suitable in the future. Currently, most class file generation in the JDK explicitly set ACC_SUPER for compatibility; we should also set this bit in the default flags, despite being no-op, in anticipation of future compatibility.
> 
> The API specifications of ClassBuilder and AccessFlags already state that an unspecified default flag for class builders are chosen, so changing this flag should be fine without extra specification changes.

Currently, most of the sites in JDK and community bytecode generation that specify access flags for a class provide an explicit `ACC_SUPER`; it is always effectively enabled since Java 8 even when it is not set.

The alternative is in valhalla, we choose a different default when the flag is default and withVersion is called. I think that is overcomplicated, and we should better just set the consensual `ACC_SUPER` flag even if the behavior has already been on by default.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24808#issuecomment-2830678906

From liach at openjdk.org  Fri Apr 25 15:15:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 25 Apr 2025 15:15:50 GMT
Subject: RFR: 8355301: Simplify Throwable::printStackTrace by using record
 [v4]
In-Reply-To: 
References: 
 <2FArm3JRh9gez7hXK0J3YS8U5tgVTCGxdd0y1qq1cLw=.9593786d-27dd-4bd7-819d-1cd4c125d0bd@github.com>
 
 
 
 
 
 
Message-ID: 

On Fri, 25 Apr 2025 14:21:55 GMT, Chen Liang  wrote:

>> The record has fewer source lines but doesn't the generated record class have a getter, toString(), hashCode() and equals(Object) which are not needed here?
>> What about using a lock parameter and a method handle to pass in the required features of PrintStream and PrintWriter:
>> 
>> public void printStackTrace(PrintWriter pw) {
>>     printStackTrace(pw, pw::println);
>> }
>> 
>> public void printStackTrace(PrintStream ps) {
>>     printStackTrace(ps, ps::println);
>> }
>> 
>> private void printStackTrace(Object lock, Consumer println) {
>>     synchronized(lock) {
>>     	...
>>         println.accept(this);
>>     	...
>>     }
>> }
>
> FYI lambda expressions depend on java.lang.invoke, and if anything initialized before that throws an exception and needs to print stack trace, the VM will fail with a traceless `StackOverflowError` I think. Consumer class is fine for early loading, but  to implement that, we fall back to records again.

Hmm, I just noticed we have `Appendable`; maybe we can reuse that...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24795#discussion_r2060435819

From asotona at openjdk.org  Fri Apr 25 15:21:03 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 25 Apr 2025 15:21:03 GMT
Subject: RFR: 8342206: Convenience method to check if a constant pool entry
 matches nominal descriptors [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 00:21:05 GMT, Chen Liang  wrote:

>> The ClassFile API promotes usage of constant nominal descriptors over literal strings. However, for `class` file parsing, currently the efficient way to check if a constant pool entry matches a desired descriptor is via unrolling them back to strings. However, string unrolling is ugly, and often times confusing, such as internal names versus field descriptors.
>> 
>> As a result, I propose to provide new methods that compare constant pool entries with the potential symbolic descriptors they represent. This is no less efficient as checking raw string equality, avoids exceptional failure behaviors of conversion to symbolic descriptors, and avoids potential programmer errors stemming from raw string handling. See the CSR for a full story.
>
> 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:
> 
>  - Rename UTF8 test methods to be different from other test methods
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cf-equals-sym
>  - 8342206: Convenience method to check if a constant pool entry matches nominal descriptors

Generally it looks good.

Compact form of the newly added tests is a bit beyond human readability for review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23548#issuecomment-2830721990

From asotona at openjdk.org  Fri Apr 25 15:39:44 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 25 Apr 2025 15:39:44 GMT
Subject: RFR: 8354877: DirectClassBuilder default flags should include
 ACC_SUPER
In-Reply-To: <0ranEoj50aTeRbxcIKrpenUwkjCFQdkRzixtS7CvFiY=.56a42ff8-bd0c-471b-9779-606a804391b9@github.com>
References: <0ranEoj50aTeRbxcIKrpenUwkjCFQdkRzixtS7CvFiY=.56a42ff8-bd0c-471b-9779-606a804391b9@github.com>
Message-ID: 

On Tue, 22 Apr 2025 23:55:54 GMT, Chen Liang  wrote:

> In the future value objects JEP, class files must have one of ACC_IDENTITY (now ACC_SUPER), ACC_ABSTRACT, and ACC_FINAL bits set, otherwise they are rejected. The current default flag has none of these bits set, meaning that it will not be suitable in the future. Currently, most class file generation in the JDK explicitly set ACC_SUPER for compatibility; we should also set this bit in the default flags, despite being no-op, in anticipation of future compatibility.
> 
> The API specifications of ClassBuilder and AccessFlags already state that an unspecified default flag for class builders are chosen, so changing this flag should be fine without extra specification changes.

OK, makes sense.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24808#pullrequestreview-2794541144

From liach at openjdk.org  Fri Apr 25 15:39:45 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 25 Apr 2025 15:39:45 GMT
Subject: RFR: 8354877: DirectClassBuilder default flags should include
 ACC_SUPER
In-Reply-To: <0ranEoj50aTeRbxcIKrpenUwkjCFQdkRzixtS7CvFiY=.56a42ff8-bd0c-471b-9779-606a804391b9@github.com>
References: <0ranEoj50aTeRbxcIKrpenUwkjCFQdkRzixtS7CvFiY=.56a42ff8-bd0c-471b-9779-606a804391b9@github.com>
Message-ID: 

On Tue, 22 Apr 2025 23:55:54 GMT, Chen Liang  wrote:

> In the future value objects JEP, class files must have one of ACC_IDENTITY (now ACC_SUPER), ACC_ABSTRACT, and ACC_FINAL bits set, otherwise they are rejected. The current default flag has none of these bits set, meaning that it will not be suitable in the future. Currently, most class file generation in the JDK explicitly set ACC_SUPER for compatibility; we should also set this bit in the default flags, despite being no-op, in anticipation of future compatibility.
> 
> The API specifications of ClassBuilder and AccessFlags already state that an unspecified default flag for class builders are chosen, so changing this flag should be fine without extra specification changes.

Oh, in [JVMS 4.1](https://docs.oracle.com/javase/specs/jvms/se24/html/jvms-4.html#jvms-4.1) `access_flags` section:

> Compilers to the instruction set of the Java Virtual Machine should set the `ACC_SUPER` flag.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24808#issuecomment-2830760072

From iklam at openjdk.org  Fri Apr 25 15:52:46 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 25 Apr 2025 15:52:46 GMT
Subject: RFR: 8342283: CDS cannot handle a large number of classes
In-Reply-To: 
References: 
Message-ID: <6YJdnjRBIScIrUmAQAjjQECuv8yFdXsGC3ZrMaXTHE0=.059d1411-c95c-4fe4-a9e0-f57ab36a4e61@github.com>

On Fri, 25 Apr 2025 14:49:37 GMT, Aleksey Shipilev  wrote:

> CDS cannot handle large number of classes, because `ClassLoader` data structures get too large for CDS archival. The new test captures such an occasion. We do `clear()`-s, but that is not enough to trim the backing storages for the affected collections.
> 
> In contrast with previous attempts to fix this (https://github.com/openjdk/jdk/pull/21797 and my VM-side field overwrite), we can just reinitialize the fields using `Unsafe`, which bypasses normal `final` field write restriction. `ClassLoader` already does a similar thing nearby! This allows us to stay fully in Java, and makes the patch fairly straightforward.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, new test reliably fails without the fix, passes with it
>  - [x] Linux x86_64 server fastdebug, `runtime/cds`

LGTM. This does look a cleaner fix.

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24877#pullrequestreview-2794570049

From bpb at openjdk.org  Fri Apr 25 16:03:48 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 25 Apr 2025 16:03:48 GMT
Subject: RFR: 8355443: [java.io] Use @requires tag instead of exiting based
 on File.separatorChar value
In-Reply-To: 
References: 
 
 
 <99snxMdIvwClX8j8gTmDfqo_RTgioRwN-lU346U2UJo=.bd60f9b1-dff2-468d-b17d-5ef454b69c9c@github.com>
 <1asenKPdexHlF3nn-pOdwRF-yfUk3BbaRTNrIZHwNuI=.56e09305-d3e6-4481-b72a-5702aae5099a@github.com>
 
Message-ID: 

On Thu, 24 Apr 2025 17:22:15 GMT, Naoto Sato  wrote:

>> Sounds like a different issue needs to be filed.
>
> Yeah, that sounds better.

See https://bugs.openjdk.org/browse/JDK-8355558

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24838#discussion_r2060508271

From bpb at openjdk.org  Fri Apr 25 16:07:45 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 25 Apr 2025 16:07:45 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value
In-Reply-To: 
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
 
Message-ID: <-j3O6p26KoZnaEJjtVcQyCg_D9bus1P6stdKfV4OVzk=.a43bf6f9-e849-413e-b5b7-0ac00a490a5c@github.com>

On Fri, 25 Apr 2025 10:18:37 GMT, Mark Sheppard  wrote:

> When running test locally that's fine, this is easily seen in the jtreg report, but when run in the test frameworks CI pipeline, this "not run " visibility is obscured. Thus when doing test run audit of a jobs, requires a bit more effort to locate test that have not been run.

Maybe the visibility in CI testing should be addressed?

> An alternative practice has been to throw a SkippedException and this is more easily observed in a pipeline job's results, as the SkippedException are part of all results, and jtreg now reports Skipped tests in its summary

Do you think it would be better overall to use `SkippedException` instead of `@requires`, or only in certain cases, e.g., `MacPathTest`, etc.?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24860#issuecomment-2830826685

From ccheung at openjdk.org  Fri Apr 25 16:15:02 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 25 Apr 2025 16:15:02 GMT
Subject: RFR: 8352003: Support --add-opens with -XX:+AOTClassLinking
In-Reply-To: 
References: 
 
 
 
Message-ID: <7qy4aZ72MJq3LvBoYiPfRsHFlnk0rReYolCwi8rErGA=.ee061fb0-c448-43eb-bb3e-5db0a51f07c7@github.com>

On Fri, 18 Apr 2025 01:41:36 GMT, Ioi Lam  wrote:

>>> Do we have a test case where `--add-opens` is used both at dump time and run time? That will verify that `--add-opens` at dump time is correctly processed.
>>> 
>> 
>> Yes, the new test `AddopensOption.java` uses the `--add-opens` both at dump time and run time.
>> I have done some minor cleanup on the test, please review the new version.
>
>> > Do we have a test case where `--add-opens` is used both at dump time and run time? That will verify that `--add-opens` at dump time is correctly processed.
>> 
>> Yes, the new test `AddopensOption.java` uses the `--add-opens` both at dump time and run time. I have done some minor cleanup on the test, please review the new version.
> 
> AddopensOption.java only checks if the --add-opens is accepted. It doesn't check if the option has any effect. I think it's better to run `TEST_MODULE1` to make sure that `setAccessible` can be called without throwing an exception. That will verify that the option has achieved the intended effect.

Thanks @iklam @AlanBateman @matias9927 for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24695#issuecomment-2830839597

From ccheung at openjdk.org  Fri Apr 25 16:15:03 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 25 Apr 2025 16:15:03 GMT
Subject: Integrated: 8352003: Support --add-opens with -XX:+AOTClassLinking
In-Reply-To: 
References: 
Message-ID: 

On Wed, 16 Apr 2025 18:21:41 GMT, Calvin Cheung  wrote:

> This RFE allows --add-opens to be specified for AOT cache creation. AOT cache can be used during production run with --add-opens option as long as the same set of options is used during assembly phase.
> 
> Passed tiers 1 - 4 testing.

This pull request has now been integrated.

Changeset: 597bcc69
Author:    Calvin Cheung 
URL:       https://git.openjdk.org/jdk/commit/597bcc695347544b9feffc5280741b1e9e1715f7
Stats:     294 lines in 9 files changed: 204 ins; 44 del; 46 mod

8352003: Support --add-opens with -XX:+AOTClassLinking

Co-authored-by: Alan Bateman 
Reviewed-by: iklam, alanb, matsaave

-------------

PR: https://git.openjdk.org/jdk/pull/24695

From smarks at openjdk.org  Fri Apr 25 16:36:04 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 25 Apr 2025 16:36:04 GMT
Subject: Integrated: 8350703: Add standard system property stdin.encoding
In-Reply-To: 
References: 
Message-ID: <-vmcfy_1O7Qx4zQHjoUGvHJhMD0weWIcr-yGTuhOTGc=.040ebd1b-476a-4982-8646-59293decbdd6@github.com>

On Thu, 17 Apr 2025 18:59:33 GMT, Stuart Marks  wrote:

> * Windows and Unix: set sprops.stdin_encoding if connected to a console
> * Add specs for stdin.encoding
> * Adjust specs to change "undefined" to "unspecified"
> * Rewrite System.in spec to refer to new property and to clarify usage with classes that perform encoding
> * Update property test

This pull request has now been integrated.

Changeset: 15f42e34
Author:    Stuart Marks 
URL:       https://git.openjdk.org/jdk/commit/15f42e348d4068bd90dd75b270a372353fe0ed07
Stats:     54 lines in 7 files changed: 29 ins; 1 del; 24 mod

8350703: Add standard system property stdin.encoding

Reviewed-by: naoto, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/24738

From bpb at openjdk.org  Fri Apr 25 16:37:01 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 25 Apr 2025 16:37:01 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value
In-Reply-To: 
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
 
Message-ID: <3BsF94c73EoYHTwLfWZNcK54QFprGFVUvmJt2kEaUJw=.91ea79d6-5d35-4e49-b1fd-ec5fe31dfb97@github.com>

On Fri, 25 Apr 2025 07:19:32 GMT, Jaikiran Pai  wrote:

>> Use the `@requires` tag instead of obtaining the operating system name from the `os.name` property and then exiting if the test is not run on that operating system.
>
> test/jdk/java/io/File/MacPathTest.java line 28:
> 
>> 26:  * @summary Tests paths on macOS
>> 27:  * @requires (os.family == "mac")
>> 28:  */
> 
> The missing `@test` on this looked odd, since that would mean that this test wasn't being run at all so far.
> 
> I went back and looked at the original RFR which introduced this test for https://bugs.openjdk.org/browse/JDK-7130915. The RFR is here https://mail.openjdk.org/pipermail/core-libs-dev/2012-June/010621.html. Going through the webrevs posted there, it appears that this was initially a shell test and had `@test` declaration.
> 
> Then in https://bugs.openjdk.org/browse/JDK-8181912 we refactored it to be a java jtreg test. The RFR for that is here https://mail.openjdk.org/pipermail/core-libs-dev/2017-June/048225.html. Going through this refactor RFR, the final webrev that was settled upon and integrated appears to be this https://mail.openjdk.org/pipermail/core-libs-dev/2017-June/048319.html. So what that refactoring did was (https://cr.openjdk.org/~mli/8181912/webrev.01/) it moved the `@test` declaration to a new file `test/java/io/File/MacPath.java` which is what then launches this `test/jdk/java/io/File/MacPathTest.java`'s main method using `ProcessBuilder`. So this `MacPathTest.java` isn't really the jtreg `@test`. 
> 
> Given this, i think we shouldn't be adding this `@test` declaration here and `MacPath.java` already has the necessary `@requires (os.family == "mac")`. 
> 
> What we should probably do (if you prefer in a different issue/PR), is perhaps add a comment to this file that it gets launched through `MacPath.java` and also maybe remove the `os.name` checks in the `main()` method of this class.

Thanks, @jaikiran, for the detailed investigation. I went partway down that road but clearly not far enough. I'll update it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24860#discussion_r2060554322

From liach at openjdk.org  Fri Apr 25 16:37:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 25 Apr 2025 16:37:05 GMT
Subject: RFR: 8354877: DirectClassBuilder default flags should include
 ACC_SUPER
In-Reply-To: <0ranEoj50aTeRbxcIKrpenUwkjCFQdkRzixtS7CvFiY=.56a42ff8-bd0c-471b-9779-606a804391b9@github.com>
References: <0ranEoj50aTeRbxcIKrpenUwkjCFQdkRzixtS7CvFiY=.56a42ff8-bd0c-471b-9779-606a804391b9@github.com>
Message-ID: 

On Tue, 22 Apr 2025 23:55:54 GMT, Chen Liang  wrote:

> In the future value objects JEP, class files must have one of ACC_IDENTITY (now ACC_SUPER), ACC_ABSTRACT, and ACC_FINAL bits set, otherwise they are rejected. The current default flag has none of these bits set, meaning that it will not be suitable in the future. Currently, most class file generation in the JDK explicitly set ACC_SUPER for compatibility; we should also set this bit in the default flags, despite being no-op, in anticipation of future compatibility.
> 
> The API specifications of ClassBuilder and AccessFlags already state that an unspecified default flag for class builders are chosen, so changing this flag should be fine without extra specification changes.

Thanks for the reviews! Meanwhile I will keep working on valhalla and its supports to move it forward.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24808#issuecomment-2830886921

From liach at openjdk.org  Fri Apr 25 16:37:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 25 Apr 2025 16:37:05 GMT
Subject: Integrated: 8354877: DirectClassBuilder default flags should include
 ACC_SUPER
In-Reply-To: <0ranEoj50aTeRbxcIKrpenUwkjCFQdkRzixtS7CvFiY=.56a42ff8-bd0c-471b-9779-606a804391b9@github.com>
References: <0ranEoj50aTeRbxcIKrpenUwkjCFQdkRzixtS7CvFiY=.56a42ff8-bd0c-471b-9779-606a804391b9@github.com>
Message-ID: <6RmZGM7VD2ggc71ghFVNnjN7EsX7NjOYgIQzq8jEzoU=.bb314547-210b-4332-a366-57048805dd4d@github.com>

On Tue, 22 Apr 2025 23:55:54 GMT, Chen Liang  wrote:

> In the future value objects JEP, class files must have one of ACC_IDENTITY (now ACC_SUPER), ACC_ABSTRACT, and ACC_FINAL bits set, otherwise they are rejected. The current default flag has none of these bits set, meaning that it will not be suitable in the future. Currently, most class file generation in the JDK explicitly set ACC_SUPER for compatibility; we should also set this bit in the default flags, despite being no-op, in anticipation of future compatibility.
> 
> The API specifications of ClassBuilder and AccessFlags already state that an unspecified default flag for class builders are chosen, so changing this flag should be fine without extra specification changes.

This pull request has now been integrated.

Changeset: ac05002c
Author:    Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/ac05002cbeb014036ffbbcb17bb12d8d2102c7cd
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8354877: DirectClassBuilder default flags should include ACC_SUPER

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/24808

From liach at openjdk.org  Fri Apr 25 16:36:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 25 Apr 2025 16:36:59 GMT
Subject: RFR: 8342206: Convenience method to check if a constant pool entry
 matches nominal descriptors [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Apr 2025 00:21:05 GMT, Chen Liang  wrote:

>> The ClassFile API promotes usage of constant nominal descriptors over literal strings. However, for `class` file parsing, currently the efficient way to check if a constant pool entry matches a desired descriptor is via unrolling them back to strings. However, string unrolling is ugly, and often times confusing, such as internal names versus field descriptors.
>> 
>> As a result, I propose to provide new methods that compare constant pool entries with the potential symbolic descriptors they represent. This is no less efficient as checking raw string equality, avoids exceptional failure behaviors of conversion to symbolic descriptors, and avoids potential programmer errors stemming from raw string handling. See the CSR for a full story.
>
> 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:
> 
>  - Rename UTF8 test methods to be different from other test methods
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cf-equals-sym
>  - 8342206: Convenience method to check if a constant pool entry matches nominal descriptors

Thanks for the review. I have updated the tests to move the actually tested contents to the human-readable parameterized tests; unfortunately the process of spawning pool entries is very complicated and I have to keep it in the huge block in the bottom of the file.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23548#issuecomment-2830885288

From liach at openjdk.org  Fri Apr 25 16:36:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 25 Apr 2025 16:36:53 GMT
Subject: RFR: 8342206: Convenience method to check if a constant pool entry
 matches nominal descriptors [v3]
In-Reply-To: 
References: 
Message-ID: 

> The ClassFile API promotes usage of constant nominal descriptors over literal strings. However, for `class` file parsing, currently the efficient way to check if a constant pool entry matches a desired descriptor is via unrolling them back to strings. However, string unrolling is ugly, and often times confusing, such as internal names versus field descriptors.
> 
> As a result, I propose to provide new methods that compare constant pool entries with the potential symbolic descriptors they represent. This is no less efficient as checking raw string equality, avoids exceptional failure behaviors of conversion to symbolic descriptors, and avoids potential programmer errors stemming from raw string handling. See the CSR for a full story.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Extract the actual tests, move pool entry spawning to the bottom
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cf-equals-sym
 - Rename UTF8 test methods to be different from other test methods
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cf-equals-sym
 - 8342206: Convenience method to check if a constant pool entry matches nominal descriptors

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23548/files
  - new: https://git.openjdk.org/jdk/pull/23548/files/dd3adbc9..1f3cc936

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23548&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23548&range=01-02

  Stats: 14467 lines in 469 files changed: 10053 ins; 3405 del; 1009 mod
  Patch: https://git.openjdk.org/jdk/pull/23548.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23548/head:pull/23548

PR: https://git.openjdk.org/jdk/pull/23548

From bpb at openjdk.org  Fri Apr 25 16:50:42 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 25 Apr 2025 16:50:42 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value [v2]
In-Reply-To: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
Message-ID: 

> Use the `@requires` tag instead of obtaining the operating system name from the `os.name` property and then exiting if the test is not run on that operating system.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8355444: Revert addition of @requires to MacPathTest and add a comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24860/files
  - new: https://git.openjdk.org/jdk/pull/24860/files/c82180b6..5d246456

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24860&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24860&range=00-01

  Stats: 8 lines in 1 file changed: 0 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24860/head:pull/24860

PR: https://git.openjdk.org/jdk/pull/24860

From bpb at openjdk.org  Fri Apr 25 16:55:56 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 25 Apr 2025 16:55:56 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value [v2]
In-Reply-To: <3BsF94c73EoYHTwLfWZNcK54QFprGFVUvmJt2kEaUJw=.91ea79d6-5d35-4e49-b1fd-ec5fe31dfb97@github.com>
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
 
 <3BsF94c73EoYHTwLfWZNcK54QFprGFVUvmJt2kEaUJw=.91ea79d6-5d35-4e49-b1fd-ec5fe31dfb97@github.com>
Message-ID: 

On Fri, 25 Apr 2025 16:33:59 GMT, Brian Burkhalter  wrote:

>> test/jdk/java/io/File/MacPathTest.java line 28:
>> 
>>> 26:  * @summary Tests paths on macOS
>>> 27:  * @requires (os.family == "mac")
>>> 28:  */
>> 
>> The missing `@test` on this looked odd, since that would mean that this test wasn't being run at all so far.
>> 
>> I went back and looked at the original RFR which introduced this test for https://bugs.openjdk.org/browse/JDK-7130915. The RFR is here https://mail.openjdk.org/pipermail/core-libs-dev/2012-June/010621.html. Going through the webrevs posted there, it appears that this was initially a shell test and had `@test` declaration.
>> 
>> Then in https://bugs.openjdk.org/browse/JDK-8181912 we refactored it to be a java jtreg test. The RFR for that is here https://mail.openjdk.org/pipermail/core-libs-dev/2017-June/048225.html. Going through this refactor RFR, the final webrev that was settled upon and integrated appears to be this https://mail.openjdk.org/pipermail/core-libs-dev/2017-June/048319.html. So what that refactoring did was (https://cr.openjdk.org/~mli/8181912/webrev.01/) it moved the `@test` declaration to a new file `test/java/io/File/MacPath.java` which is what then launches this `test/jdk/java/io/File/MacPathTest.java`'s main method using `ProcessBuilder`. So this `MacPathTest.java` isn't really the jtreg `@test`. 
>> 
>> Given this, i think we shouldn't be adding this `@test` declaration here and `MacPath.java` already has the necessary `@requires (os.family == "mac")`. 
>> 
>> What we should probably do (if you prefer in a different issue/PR), is perhaps add a comment to this file that it gets launched through `MacPath.java` and also maybe remove the `os.name` checks in the `main()` method of this class.
>
> Thanks, @jaikiran, for the detailed investigation. I went partway down that road but clearly not far enough. I'll update it.

I replaced the `@test` block with a plain comment in 5d24645 and removed the vestigial check of `os.name`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24860#discussion_r2060577848

From naoto at openjdk.org  Fri Apr 25 17:07:38 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 25 Apr 2025 17:07:38 GMT
Subject: RFR: 8355558: SJIS.java test is always ignored
Message-ID: 

Stemmed from this PR: https://github.com/openjdk/jdk/pull/24838
After JEP 400, `file.encoding` is always UTF-8, so the test was never run. Using `native.encoding` is appropriate so that the intention of the initial test will hold. Tested on an English Windows in which the system locale is set to `Japanese(Japan)`, and confirmed it succeeded without SkippedException.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/24881/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24881&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355558
  Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24881.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24881/head:pull/24881

PR: https://git.openjdk.org/jdk/pull/24881

From bchristi at openjdk.org  Fri Apr 25 17:09:12 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 25 Apr 2025 17:09:12 GMT
Subject: Integrated: 8305186: Reference.waitForReferenceProcessing should be
 more accessible to tests
In-Reply-To: 
References: 
Message-ID: <4i5pKQSZCxSz6fnPW_eyvlMlUwgyTMSb618vSrEmluQ=.91333717-5ebb-4358-8dee-fcce1d0aac47@github.com>

On Tue, 8 Apr 2025 20:20:56 GMT, Brent Christian  wrote:

> Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead to intermittent test failures ([JDK-8298783](https://bugs.openjdk.org/browse/JDK-8298783)  is a recent example).
> 
> A better mechanism already exists in the private `Reference.waitForReferenceProcessing()` method. This PR makes `waitForReferenceProcessing()` available to tests via the `WhiteBox` and `ForceGC` test libraries.

This pull request has now been integrated.

Changeset: d8f012ea
Author:    Brent Christian 
URL:       https://git.openjdk.org/jdk/commit/d8f012ea2a0514020434d5db6047e36941e9349b
Stats:     51 lines in 1 file changed: 51 ins; 0 del; 0 mod

8305186: Reference.waitForReferenceProcessing should be more accessible to tests

Reviewed-by: kbarrett

-------------

PR: https://git.openjdk.org/jdk/pull/24527

From jbhateja at openjdk.org  Fri Apr 25 17:27:53 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 25 Apr 2025 17:27:53 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v15]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 25 Apr 2025 05:26:35 GMT, Vladimir Ivanov  wrote:

>> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
>> 
>> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
>> 
>> The patch consists of the following parts:
>>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
>> 
>> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
>> 
>> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
>> 
>> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
>> 
>> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
>> 
>> Thanks!
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove UseVectorStubs usage in riscv.ad

Looks good to me.
Best Regards

-------------

Marked as reviewed by jbhateja (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24462#pullrequestreview-2794825283

From naoto at openjdk.org  Fri Apr 25 18:16:04 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 25 Apr 2025 18:16:04 GMT
Subject: RFR: 8342886: Update MET timezone in TimeZoneNames files
In-Reply-To: 
References: 
Message-ID: <8KXAJ9-KCZaXabjNJzt_txzEwml8NsIGSrR87FwG0eU=.a23343f0-cb19-4b40-b3bf-8d2390206fb3@github.com>

On Fri, 25 Apr 2025 09:57:38 GMT, Gautham Krishnan  wrote:

> MET timezone entry in TimeZoneNames.java and TimeZoneNames_*.java needs to be updated as MET is alias to Europe/Brussels as per 2024b tzdata changes.
> 
> Also Bug4848242.java needs to be removed as the test expects all euro locale time zones should have the same short names.

Thanks for the contribution.
>Also Bug4848242.java needs to be removed as the test expects all euro locale time zones should have the same short names.

I think this is still worth testing, with comments adjusted (not every euro country, but sampled ones do have the same short names)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24871#issuecomment-2831098820

From bpb at openjdk.org  Fri Apr 25 19:03:52 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 25 Apr 2025 19:03:52 GMT
Subject: RFR: 8355558: SJIS.java test is always ignored
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Apr 2025 17:02:30 GMT, Naoto Sato  wrote:

> Stemmed from this PR: https://github.com/openjdk/jdk/pull/24838
> After JEP 400, `file.encoding` is always UTF-8, so the test was never run. Using `native.encoding` is appropriate so that the intention of the initial test will hold. Tested on an English Windows in which the system locale is set to `Japanese(Japan)`, and confirmed it succeeded without SkippedException.

I don't have good knowledge of the encodings, but code-wise this looks fine.

test/jdk/java/io/pathNames/win32/SJIS.java line 32:

> 30: */
> 31: 
> 32: import java.io.*;

Maybe don't use wildcard import?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24881#issuecomment-2831200780
PR Review Comment: https://git.openjdk.org/jdk/pull/24881#discussion_r2060750924

From abarashev at openjdk.org  Fri Apr 25 19:09:55 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 25 Apr 2025 19:09:55 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
References: 
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
Message-ID: 

On Thu, 24 Apr 2025 16:59:45 GMT, Daniel Fuchs  wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement 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 409 commits:
> 
>  - merge latest changes from master branch
>  - http3: add missing 
 separator to Http3DiscoveryMode.ALT_SVC API documentation
>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>  - http3: minor improvement to log message
>  - http3: Artur's review - remove commented out code from test
>  - http3: Artur's review - make methods package private
>  - http3: qpack - allow 0 capacity when max capacity is 0
>  - Remove flow control from stream limit comments
>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe

src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 192:

> 190:      */
> 191:     static AlgorithmConstraints forQUIC(QuicTLSEngine engine,
> 192:                                         String[] allowedAlgorithms,

This should probably be renamed to `supportedAlgorithms` for consistency, to match SSLEngine and SSLSocket methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2060758541

From abarashev at openjdk.org  Fri Apr 25 19:15:59 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 25 Apr 2025 19:15:59 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
References: 
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
Message-ID: 

On Thu, 24 Apr 2025 16:59:45 GMT, Daniel Fuchs  wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement 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 409 commits:
> 
>  - merge latest changes from master branch
>  - http3: add missing 
 separator to Http3DiscoveryMode.ALT_SVC API documentation
>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>  - http3: minor improvement to log message
>  - http3: Artur's review - remove commented out code from test
>  - http3: Artur's review - make methods package private
>  - http3: qpack - allow 0 capacity when max capacity is 0
>  - Remove flow control from stream limit comments
>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe

src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 172:

> 170:             userSpecifiedConstraints = engine.getSSLParameters()
> 171:                     .getAlgorithmConstraints();
> 172:         }

Duplicate code block here and in the 2nd `forQUIC` method. We should move it to a private `getUserSpecifiedConstraints` method, like in SSLEngine and SSLSocket cases. In fact I think all 3 methods could be combined into a single `getUserSpecifiedConstraints(Object o)` since they all do the same thing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2060764346

From jiangli at openjdk.org  Fri Apr 25 19:19:46 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 25 Apr 2025 19:19:46 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: 
References: 
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
 
Message-ID: 

On Fri, 25 Apr 2025 11:31:50 GMT, Jaikiran Pai  wrote:

> Hello Jiangli, if I understand this change correctly, then this is forcing a non-JNI library to be a JNI library for it to work on static JDK. Is that a requirement for static JDK builds? Or is it just a convenient way to use existing library loading mechanism in the `jdk.internal.loader.NativeLibraries`?
> 

Hi @jaikiran Good questions. I kind of expected questions like those might be raised with the addition of `DEF_STATIC_JNI_OnLoad` to `libsyslookup`, when I made the change.

The original static built-in JNI library support in JDK was added by JEP 178 (https://openjdk.org/jeps/178) "Statically-Linked JNI Libraries" work. It's on top of the JNI library support. Both spec & implementation expected `JNI_OnLoad_L` (L as the library name) in a statically linked JNI library. From JNI spec (https://docs.oracle.com/en/java/javase/24/docs/specs/jni/invocation.html#jni_onload_l):


JNI_OnLoad_L
jint JNI_Onload_(JavaVM *vm, void *reserved);

Mandatory function that must be defined by statically linked libraries .

If a library, named 'L', is statically linked, then upon the first invocation of System.loadLibrary("L") or equivalent API, a JNI_OnLoad_L function will be invoked with the same arguments and expected return value as specified for the JNI_OnLoad function. JNI_OnLoad_L must return the JNI version needed by the native library. This version must be JNI_VERSION_1_8 or later. If the VM does not recognize the version number returned by JNI_OnLoad_L, the VM will act as if the library was never loaded.

LINKAGE:
Exported from statically linked native libraries that contain native method implementations.

PARAMETERS:
vm: a pointer to the current VM structure.

reserved: unused pointer.

RETURNS:
Return the required JNI_VERSION constant (see also GetVersion). The minimum version returned being at least JNI_VERSION_1_8.

SINCE:
JDK/JRE 1.8

JNI_OnUnload_L
void JNI_OnUnload_(JavaVM *vm, void *reserved);

Optional function defined by statically linked libraries. When the class loader containing a statically linked native library 'L' is garbage collected, the VM will invoke the JNI_OnUnload_L function of the library if such a function is exported.

This function can be used to perform cleanup operations. Because this function is called in an unknown context (such as from a finalizer), the programmer should be conservative on using Java VM services, and refrain from arbitrary Java call-backs.

LINKAGE:
Exported from statically linked native libraries that contain native method implementations.

PARAMETERS:
vm: a pointer to the current VM structure.

reserved: unused pointer.

SINCE:
JDK/JRE 1.8

Informational Note:
The act of loading a native library is the complete process of making the library and its native entry points known and registered to the Java VM and runtime. Note that simply performing operating system level operations to load a native library, such as dlopen on a UNIX(R) system, does not fully accomplish this goal. A native function is normally called from the Java class loader to perform a call to the host operating system that will load the library into memory and return a handle to the native library. This handle will be stored and used in subsequent searches for native library entry points. The Java native class loader will complete the load process once the handle is successfully returned to register the library.


You are right that this PR change turns the `libsyslookup` from a "non-JNI" native library to JNI native library. The `DEF_STATIC_JNI_OnLoad` macro adds `JNI_OnLoad_syslookup` in libsyslookup. The `JNI_OnLoad_syslookup` symbol can be used by `Java_jdk_internal_loader_NativeLibraries_findBuiltinLib` (https://github.com/openjdk/jdk/blob/4b880299881c9413038d647123e3b658999c6f8f/src/java.base/share/native/libjava/NativeLibraries.c#L235) to find the statically linked library.

> Are there other similar libraries shipped in JAVA_HOME/lib that would require a similar change/treatment?

Yes. Our current static/hermetic work has found any missing `DEF_STATIC_JNI_OnLoad` in the JDK JNI libraries and added them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2831236496

From abarashev at openjdk.org  Fri Apr 25 19:33:00 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 25 Apr 2025 19:33:00 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
References: 
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
Message-ID: <04qyL7y-HmZj4Z_m1tc--rIZHU9aJlczhSGBQCVkWxc=.b4f05b83-6166-479f-871b-cfd03c00d9f6@github.com>

On Thu, 24 Apr 2025 16:59:45 GMT, Daniel Fuchs  wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement 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 409 commits:
> 
>  - merge latest changes from master branch
>  - http3: add missing 
 separator to Http3DiscoveryMode.ALT_SVC API documentation
>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>  - http3: minor improvement to log message
>  - http3: Artur's review - remove commented out code from test
>  - http3: Artur's review - make methods package private
>  - http3: qpack - allow 0 capacity when max capacity is 0
>  - Remove flow control from stream limit comments
>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe

src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 275:

> 273:         final X509Certificate[] trustedChain = v.validate(chain, null,
> 274:                 responseList, constraints, authType);
> 275:         if (sslParameters != null && handshakeSession != null) {

Looks like this `if` block is not needed: `sslParameters != null` condition is always `true`, and we should throw an exception in the beginning of the method if session is null.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2060782742

From naoto at openjdk.org  Fri Apr 25 19:41:55 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 25 Apr 2025 19:41:55 GMT
Subject: RFR: 8355558: SJIS.java test is always ignored [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 25 Apr 2025 19:00:43 GMT, Brian Burkhalter  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Expand wild card imports
>
> test/jdk/java/io/pathNames/win32/SJIS.java line 32:
> 
>> 30: */
>> 31: 
>> 32: import java.io.*;
> 
> Maybe don't use wildcard import?

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24881#discussion_r2060792422

From heidinga at openjdk.org  Fri Apr 25 19:41:52 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 25 Apr 2025 19:41:52 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 25 Apr 2025 05:56:15 GMT, Ioi Lam  wrote:

>> This PR contains 2 parts
>> 
>> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
>> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.
>> 
>> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):
>> 
>> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
>> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 
>> 
>> `ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:
>> 
>> - If an entry has not yet been collected, we make sure it will never be collected.
>> - If an entry has been collected, we remove it from the table
>> 
>> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.
>> 
>> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.
>> 
>> In the future, we may relax the implementation to allow for other use cases.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @fisk comment

src/hotspot/share/cds/aotReferenceObjSupport.cpp line 76:

> 74: // the use of Weak/Soft references used by java.lang.invoke.
> 75: //
> 76: // We intent to evolve the implementation in the future by

Suggestion:

// We intend to evolve the implementation in the future by

src/hotspot/share/cds/aotReferenceObjSupport.cpp line 106:

> 104:     assert(CDSConfig::allow_only_single_java_thread(), "Required");
> 105: 
> 106:     TempNewSymbol method_name = SymbolTable::new_symbol("prepareForAOTCache");

I'm slightly uncomfortable with using the same method name (`prepareForAOTCache`) on MethodType and on ReferenceKeyMap & ReferenceKeySet as they have different expected use cases.  The one on MT is the "front door" the VM calls to remove stale Reference objects while the RKMap/RKSet are internal mechanisms that the VM would never call except for MT triggering it.

Does it make sense to use different names for these methods?  The MT one is a hook that could be extended to other classes to prepare them for cache creation while we wouldn't treat the RKMap/RKSet ones in the same way.  Maybe append "_internal" or "_helper" to the RFMap/Set methods to distinguish them?

src/java.base/share/classes/jdk/internal/misc/CDS.java line 93:

> 91: 
> 92: 
> 93:     private static ArrayList keepAliveList;

Is it worth adding a comment stating this list should only be populated during an assembly phase?  That it should be null in both training and production runs?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2060769019
PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2060794048
PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2060762727

From naoto at openjdk.org  Fri Apr 25 19:41:54 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 25 Apr 2025 19:41:54 GMT
Subject: RFR: 8355558: SJIS.java test is always ignored [v2]
In-Reply-To: 
References: 
Message-ID: 

> Stemmed from this PR: https://github.com/openjdk/jdk/pull/24838
> After JEP 400, `file.encoding` is always UTF-8, so the test was never run. Using `native.encoding` is appropriate so that the intention of the initial test will hold. Tested on an English Windows in which the system locale is set to `Japanese(Japan)`, and confirmed it succeeded without SkippedException.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Expand wild card imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24881/files
  - new: https://git.openjdk.org/jdk/pull/24881/files/670228c7..76aac517

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24881&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24881&range=00-01

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24881.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24881/head:pull/24881

PR: https://git.openjdk.org/jdk/pull/24881

From lmesnik at openjdk.org  Fri Apr 25 19:42:53 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 25 Apr 2025 19:42:53 GMT
Subject: RFR: 8342283: CDS cannot handle a large number of classes
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Apr 2025 14:49:37 GMT, Aleksey Shipilev  wrote:

> CDS cannot handle large number of classes, because `ClassLoader` data structures get too large for CDS archival. The new test captures such an occasion. We do `clear()`-s, but that is not enough to trim the backing storages for the affected collections.
> 
> In contrast with previous attempts to fix this (https://github.com/openjdk/jdk/pull/21797 and my VM-side field overwrite), we can just reinitialize the fields using `Unsafe`, which bypasses normal `final` field write restriction. `ClassLoader` already does a similar thing nearby! This allows us to stay fully in Java, and makes the patch fairly straightforward.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, new test reliably fails without the fix, passes with it
>  - [x] Linux x86_64 server fastdebug, `runtime/cds`

Test changes looks good for me.

-------------

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24877#pullrequestreview-2795129983

From abarashev at openjdk.org  Fri Apr 25 19:45:00 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 25 Apr 2025 19:45:00 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
References: 
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
Message-ID: 

On Thu, 24 Apr 2025 16:59:45 GMT, Daniel Fuchs  wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement 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 409 commits:
> 
>  - merge latest changes from master branch
>  - http3: add missing 
 separator to Http3DiscoveryMode.ALT_SVC API documentation
>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>  - http3: minor improvement to log message
>  - http3: Artur's review - remove commented out code from test
>  - http3: Artur's review - make methods package private
>  - http3: qpack - allow 0 capacity when max capacity is 0
>  - Remove flow control from stream limit comments
>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 532:

> 530:     }
> 531: 
> 532:     public boolean isQuic() {

This method never called.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2060797765

From duke at openjdk.org  Fri Apr 25 20:14:25 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Fri, 25 Apr 2025 20:14:25 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms
Message-ID: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>

The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm.

The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b15](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B15) as the baseline version.

For performance data collected with the built in **cbrt** micro-benchmark, see the table below. Each result is the mean of 8 individual runs. Overall, the intrinsic provides a performance uplift of 41%.

| Benchmark        | Throughput with baseline (op/s) | Throughput with intrinsic (op/s) | Speedup |
| :----------------: | :----------------------------------: | :----------------------------------: | :---------: |
| MathBench.cbrt | 148242                                        | 209122                                        | 1.41x       |

Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes.

-------------

Commit messages:
 - Change coeff_table alignment from 4 bytes to 16 bytes to conform with movapd instruction
 - Merge branch 'master' into user/missa-prime/cbrt
 - x86_64 intrinsic for cbrt using libm

Changes: https://git.openjdk.org/jdk/pull/24470/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24470&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353686
  Stats: 466 lines in 26 files changed: 453 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/24470.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24470/head:pull/24470

PR: https://git.openjdk.org/jdk/pull/24470

From bpb at openjdk.org  Fri Apr 25 20:36:45 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 25 Apr 2025 20:36:45 GMT
Subject: RFR: 8355558: SJIS.java test is always ignored [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 25 Apr 2025 19:41:54 GMT, Naoto Sato  wrote:

>> Stemmed from this PR: https://github.com/openjdk/jdk/pull/24838
>> After JEP 400, `file.encoding` is always UTF-8, so the test was never run. Using `native.encoding` is appropriate so that the intention of the initial test will hold. Tested on an English Windows in which the system locale is set to `Japanese(Japan)`, and confirmed it succeeded without SkippedException.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Expand wild card imports

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24881#pullrequestreview-2795227295

From bpb at openjdk.org  Fri Apr 25 20:36:46 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 25 Apr 2025 20:36:46 GMT
Subject: RFR: 8355558: SJIS.java test is always ignored [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 25 Apr 2025 19:37:17 GMT, Naoto Sato  wrote:

>> test/jdk/java/io/pathNames/win32/SJIS.java line 32:
>> 
>>> 30: */
>>> 31: 
>>> 32: import java.io.*;
>> 
>> Maybe don't use wildcard import?
>
> Fixed.

Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24881#discussion_r2060851511

From ccheung at openjdk.org  Fri Apr 25 20:44:48 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 25 Apr 2025 20:44:48 GMT
Subject: RFR: 8342283: CDS cannot handle a large number of classes
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Apr 2025 14:49:37 GMT, Aleksey Shipilev  wrote:

> CDS cannot handle large number of classes, because `ClassLoader` data structures get too large for CDS archival. The new test captures such an occasion. We do `clear()`-s, but that is not enough to trim the backing storages for the affected collections.
> 
> In contrast with previous attempts to fix this (https://github.com/openjdk/jdk/pull/21797 and my VM-side field overwrite), we can just reinitialize the fields using `Unsafe`, which bypasses normal `final` field write restriction. `ClassLoader` already does a similar thing nearby! This allows us to stay fully in Java, and makes the patch fairly straightforward.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, new test reliably fails without the fix, passes with it
>  - [x] Linux x86_64 server fastdebug, `runtime/cds`

LGTM.

-------------

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24877#pullrequestreview-2795241761

From vlivanov at openjdk.org  Fri Apr 25 21:22:52 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 25 Apr 2025 21:22:52 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v15]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 25 Apr 2025 05:26:35 GMT, Vladimir Ivanov  wrote:

>> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
>> 
>> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
>> 
>> The patch consists of the following parts:
>>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
>> 
>> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
>> 
>> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
>> 
>> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
>> 
>> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
>> 
>> Thanks!
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove UseVectorStubs usage in riscv.ad

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24462#issuecomment-2831450883

From vlivanov at openjdk.org  Fri Apr 25 21:26:54 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 25 Apr 2025 21:26:54 GMT
Subject: RFR: 8353786: Migrate Vector API math library support to FFM API
 [v13]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Fri, 25 Apr 2025 09:41:21 GMT, Jatin Bhateja  wrote:

>> It does look attractive, but macro expansion-based solution requires JVM to internalize such operations and their properties. 
>> 
>> IMO a higher-level solution based on more generic JVM primitives would enable libraries to properly annotate their operations in Java bytecodes/class files, so C2 can perform such type of transformations without the need to intrinsify each individual operation first. (Think of [JDK-8218414](https://bugs.openjdk.org/browse/JDK-8218414) / [JDK-8347901](https://bugs.openjdk.org/browse/JDK-8347901) on steroids.)
>
> I agree, this is a typical graph transform which cannot be applied currently because we are generating CallLeafVectorNode upfront during parsing, If we prevent intrinsification then compiler will attempt inlining, generating a much complex graph shape which may not be reducible.

I don't see any insurmountable problems performing such transformations on chains of `CallLeafVector` nodes (or any other call nodes). But the missing piece is information about the algebraic properties of native functions JVM can't derive on its own.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24462#discussion_r2060898080

From vlivanov at openjdk.org  Fri Apr 25 21:26:56 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 25 Apr 2025 21:26:56 GMT
Subject: Integrated: 8353786: Migrate Vector API math library support to FFM
 API
In-Reply-To: 
References: 
Message-ID: 

On Fri, 4 Apr 2025 22:52:24 GMT, Vladimir Ivanov  wrote:

> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in JVM) to Java FFM API.
> 
> Since FFM API doesn't support vector calling conventions yet, migration affects only symbol lookup for now. But it still enables significant simplifications on JVM side.
> 
> The patch consists of the following parts:
>   * on-demand symbol lookup in Java code replaces eager lookup from native code during JVM startup;
>   * 2 new VM intrinsics for vector calls (support unary and binary shapes) (code separated from unary/binary vector operations);
>   * new internal interface to query supported CPU ISA extensions (`jdk.incubator.vector.CPUFeatures`) used for CPU dispatching.
> 
> `java.lang.foreign` API is used to perform symbol lookup in vector math library, then the address is cached and fed into corresponding JVM intrinsic, so C2 can turn it into a direct vector call in generated code.
> 
> Once `java.lang.foreign` supports vectors & vector calling conventions, VM intrinsics can go away. 
> 
> Performance is on par with original implementation (tested with microbenchmarks on linux-x64 and macosx-aarch64).
> 
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and macosx-aarch64)
> 
> Thanks!

This pull request has now been integrated.

Changeset: e57fd710
Author:    Vladimir Ivanov 
URL:       https://git.openjdk.org/jdk/commit/e57fd710496b2ac8aa93eb3d4ff2234170fa2e37
Stats:     1309 lines in 50 files changed: 834 ins; 389 del; 86 mod

8353786: Migrate Vector API math library support to FFM API

Reviewed-by: jbhateja, kvn, psandoz, xgong, jvernee, mli

-------------

PR: https://git.openjdk.org/jdk/pull/24462

From bchristi at openjdk.org  Fri Apr 25 21:30:10 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 25 Apr 2025 21:30:10 GMT
Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed
 with "RuntimeException: MyObject is not found in test output" [v5]
In-Reply-To: 
References: 
Message-ID: <6FbcHJgoBqT54MMlshTquDhF3VwEPWlR2HXcx1hFt4o=.8f06a700-2720-467a-9d2c-7ed4af277658@github.com>

> I propose some cleanups to `FinalizerHistogramTest.java` to hopefully clear up the intermittent failures:
> 
> * run with `othervm`: this test blocks the (global) finalizer thread, and also requires the (global) finalizer thread to enter the test's `finalize()` method
> * The test uses `volatile` ints, but sets them based on their current value, which is not reliable; convert to `AtomicInteger`
> * use `PhantomReference`s to ensure that at least two `MyObject`s have become unreachable. If one is stuck in `finalize()`, at least one is still waiting to be finalized and should show up in the histogram.

Brent Christian 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 'master' into 8298783
 - convert to WeakRefs, use a RefQ, print ForceGC results
 - 'return' not needed in lambda
 - rename counter variables to use 'Count'
 - test reliability improvements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24143/files
  - new: https://git.openjdk.org/jdk/pull/24143/files/d1041073..cfbb4230

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24143&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24143&range=03-04

  Stats: 353256 lines in 4198 files changed: 101602 ins; 237660 del; 13994 mod
  Patch: https://git.openjdk.org/jdk/pull/24143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24143/head:pull/24143

PR: https://git.openjdk.org/jdk/pull/24143

From liach at openjdk.org  Fri Apr 25 21:38:22 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 25 Apr 2025 21:38:22 GMT
Subject: RFR: 8355442: Reference field lambda forms with type casts are not
 generated
Message-ID: 

Currently, we are not generating all possible field lambda forms.

Field lambda forms have these dimensions:
- get/set
- instance/static/static+class init barrier
- plain/volatile
- 8 primitive types, no-cast object, object with cast

Bringing to a total of 2 ? 3 ? 2 ? 10 = 120 lambda forms.

Previously, the ones with init barrier or object with cast types were not generated due to spamming the Kind enum. In retrospect, I believe skipping the object with cast form is a poor choice - tons of Java fields are using non-interface types. Also seems the volatile accessors were omitted in InvokerBytecodeGenerator, which made their pregen useless.

I have utilized erased method types to distinguish forms - get/set, 5 basic types, and instance/static can be distinguished by the types, so the Kind enums now only represent init, volatile, and non-basic types (byte, char, short, boolean, casts), bringing the total constants to 24 down from 40 previously.

In the long run, we should investigate update `Kind` to allow flexible representations - an enum is too restrictive especially with the erased types.

-------------

Commit messages:
 - Accidental name conflicts
 - 8355442: Reference field lambda forms with type casts are not generated

Changes: https://git.openjdk.org/jdk/pull/24887/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24887&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355442
  Stats: 159 lines in 4 files changed: 29 ins; 37 del; 93 mod
  Patch: https://git.openjdk.org/jdk/pull/24887.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24887/head:pull/24887

PR: https://git.openjdk.org/jdk/pull/24887

From liach at openjdk.org  Fri Apr 25 22:09:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 25 Apr 2025 22:09:46 GMT
Subject: RFR: 8355442: Reference field lambda forms with type casts are not
 generated
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Apr 2025 20:30:15 GMT, Chen Liang  wrote:

> Currently, we are not generating all possible field lambda forms.
> 
> Field lambda forms have these dimensions:
> - get/set
> - instance/static/static+class init barrier
> - plain/volatile
> - 8 primitive types, no-cast object, object with cast
> 
> Bringing to a total of 2 ? 3 ? 2 ? 10 = 120 lambda forms.
> 
> Previously, the ones with init barrier or object with cast types were not generated due to spamming the Kind enum. In retrospect, I believe skipping the object with cast form is a poor choice - tons of Java fields are using non-interface types. Also seems the volatile accessors were omitted in InvokerBytecodeGenerator, which made their pregen useless.
> 
> I have utilized erased method types to distinguish forms - get/set, 5 basic types, and instance/static can be distinguished by the types, so the Kind enums now only represent init, volatile, and non-basic types (byte, char, short, boolean, casts), bringing the total constants to 24 down from 40 previously.
> 
> In the long run, we should investigate update `Kind` to allow flexible representations - an enum is too restrictive especially with the erased types.

Testing: tier 1-3, one intermittent Jshell failure in tier1

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24887#issuecomment-2831517250

From jrose at openjdk.org  Fri Apr 25 22:22:45 2025
From: jrose at openjdk.org (John R Rose)
Date: Fri, 25 Apr 2025 22:22:45 GMT
Subject: RFR: 8342283: CDS cannot handle a large number of classes
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Apr 2025 14:49:37 GMT, Aleksey Shipilev  wrote:

> CDS cannot handle large number of classes, because `ClassLoader` data structures get too large for CDS archival. The new test captures such an occasion. We do `clear()`-s, but that is not enough to trim the backing storages for the affected collections.
> 
> In contrast with previous attempts to fix this (https://github.com/openjdk/jdk/pull/21797 and my VM-side field overwrite), we can just reinitialize the fields using `Unsafe`, which bypasses normal `final` field write restriction. `ClassLoader` already does a similar thing nearby! This allows us to stay fully in Java, and makes the patch fairly straightforward.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, new test reliably fails without the fix, passes with it
>  - [x] Linux x86_64 server fastdebug, `runtime/cds`

src/java.base/share/classes/java/lang/ClassLoader.java line 2590:

> 2588:      * @implNote This is done while the JVM is running in single-threaded mode,
> 2589:      * and at the very end of Java bytecode execution. We know that no more classes
> 2590:      * will be loaded and none of the fields modified by this method will be used again.

There is a tiny technical debt here.  If future AOT code generation uses a future aggressive constant folding of object fields (cf. `TrustFinalNonStaticFields`) and a constant CL reference ends up in optimized code and there is a constant-folded reference (and.. and?) it is remotely possible that the old value of the field will get wrongly embedded in AOT code.

If we arrange AOT code generation to occur after all of these fixups (in Java code) are done, then the problem will not occur.  It's a delicate set of invariants.  Your expanded comment is a good start at calling them out, but this is a long string we are pulling on.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24877#discussion_r2060872094

From smarks at openjdk.org  Sat Apr 26 00:12:44 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 26 Apr 2025 00:12:44 GMT
Subject: RFR: 8355632: WhiteBox.waitForReferenceProcessing() fails assert
 for return type
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Apr 2025 23:37:13 GMT, Brent Christian  wrote:

> The newly-added `WhiteBox.waitForReferenceProcessing()` (see [8305186](https://bugs.openjdk.org/browse/JDK-8305186)) always fails with assertions enabled.
> I've updated the assertion, and also added the test I used locally to test the new method (just not with assertions enabled, apparently.)

test/lib/jdk/test/whitebox/WhiteBox.java line 572:

> 570:         wfrp = Reference.class.getDeclaredMethod("waitForReferenceProcessing");
> 571:         wfrp.setAccessible(true);
> 572:         assert wfrp.getReturnType().equals(Class.forPrimitiveName("boolean"));

Does `boolean.class` work?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24892#discussion_r2061055041

From swen at openjdk.org  Sat Apr 26 04:04:30 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 26 Apr 2025 04:04:30 GMT
Subject: RFR: 8355636: Speed =?UTF-8?B?4oCL4oCLdXA=?=
 Throwable::printStackTrace by reducing object allocation
Message-ID: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>

In the Throwable::printStackTrace method, StringBuilder is created multiple times to build String. By sharing StringBuilder to build String, object allocation and copying are reduced.

In the scenario without suppressed and ourCause, unused IdentityHashMap is not created.

Through these optimizations, the performance of `new Exception().printStackTrace()` can be improved by about 10%.

-------------

Commit messages:
 - lineBuffer, from @liach
 - bug fix
 - bug fix
 - from @liach
 - Update src/java.base/share/classes/java/lang/Throwable.java
 - from @liach
 - Remove redundant toString
 - from @liach
 - from @liach
 - from @liach
 - ... and 2 more: https://git.openjdk.org/jdk/compare/82c24944...a68c6932

Changes: https://git.openjdk.org/jdk/pull/24864/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24864&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355636
  Stats: 252 lines in 3 files changed: 223 ins; 8 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/24864.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24864/head:pull/24864

PR: https://git.openjdk.org/jdk/pull/24864

From liach at openjdk.org  Sat Apr 26 04:04:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 26 Apr 2025 04:04:30 GMT
Subject: RFR: 8355636: Speed =?UTF-8?B?4oCL4oCLdXA=?=
 Throwable::printStackTrace by reducing object allocation
In-Reply-To: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
References: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
Message-ID: 

On Fri, 25 Apr 2025 01:36:50 GMT, Shaojin Wen  wrote:

> In the Throwable::printStackTrace method, StringBuilder is created multiple times to build String. By sharing StringBuilder to build String, object allocation and copying are reduced.
> 
> In the scenario without suppressed and ourCause, unused IdentityHashMap is not created.
> 
> Through these optimizations, the performance of `new Exception().printStackTrace()` can be improved by about 10%.

What about this version, we can reuse the StringBuilder for the enclosed because we are behind the lock. Also avoids changing caption and prefix.

Edit: removed patch to avoid mail spam, look at edit history or the gist linked below

I have thought about the prefix and caption again - the prefix is just an indent. If we reuse the buffer for line, we just reset position to the end of indent, and you don't need to worry about concating caption and prefix (actually indent) any more.

https://gist.github.com/0974e48fb01c8c2ce290ab3ced36dcc2

src/java.base/share/classes/java/lang/StackTraceElement.java line 367:

> 365:     }
> 366: 
> 367:     int estimatedLength() {

Don't think you need to split this into a new method; you can just keep the old variable as the calculation is too long.

src/java.base/share/classes/java/lang/StackTraceElement.java line 381:

> 379:      */
> 380:     StringBuilder appendTo(StringBuilder sb) {
> 381:         int length = sb.length();

Can we rename this to `startingLength` for clarity?

src/java.base/share/classes/java/lang/Throwable.java line 696:

> 694:             printStackTrace0(s, trace);
> 695: 
> 696:             java.lang.Throwable[] suppressed = getSuppressed();

Suggestion:

            Throwable[] suppressed = getSuppressed();

src/java.base/share/classes/java/lang/Throwable.java line 705:

> 703:             java.lang.Throwable[] suppressed = getSuppressed();
> 704:             if (suppressed.length > 0) {
> 705:                 dejaVu = dejaVu();

Instead of creating dejaVu() here and there, I think you can do after printStackTrace0:

printStackTrace0(s, trace);

var suppressed = getSuppressed();
var ourCause = getCause();

if (suppressed.length > 0 || cause != null) {
    // Guard against malicious overrides of Throwable.equals by
    // using a Set with identity equality semantics.
    Set dejaVu = Collections.newSetFromMap(new IdentityHashMap<>());
    dejaVu.add(this);
    // more code here
}

src/java.base/share/classes/java/lang/Throwable.java line 749:

> 747:             // Print suppressed exceptions, if any
> 748:             for (Throwable se : getSuppressed())
> 749:                 se.printEnclosedStackTrace(s, trace, SUPPRESSED_CAPTION,

Shouldn't SUPPRESSED_CAPTION be added a prefix?

I think we should revert the `prefixCaption` argument change; you should add a line `String prefixCaption = prefix.concat(caption);` instead.

src/java.base/share/classes/java/lang/Throwable.java line 785:

> 783:             StackTraceElement[] trace,
> 784:             int traceEnd,
> 785:             int framesInCommon) {

You just need to pass `framesInCommon`, can calculate `int limit = trace.length - framesInCommon;` and then for the loop below, `for (int i = 0; i < limit; i++)` instead of using `traceEnd`

src/java.base/share/classes/java/lang/Throwable.java line 804:

> 802: 
> 803:         var sb = new StringBuilder(128);
> 804:         if (prefix != null) {

I think you should can this whole thing to be cleaner:

var sb = new StringBuilder(128);
if (prefix != null)
    sb.append(prefix);
sb.append(at);
int prefixAndAtLength = sb.length();
for (int i = 0; i <= traceEnd; i++) {
    sb.setLength(prefixAndAtLength);
    printer.println(trace[i].appendTo(sb));
}

if (framesInCommon != 0) {
    sb.setLength(prefixAndAtLength - at.length())
      .append("\t... ").append(framesInCommon).append(" more");
    printer.println(sb);
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24864#issuecomment-2829331303
PR Comment: https://git.openjdk.org/jdk/pull/24864#issuecomment-2829349920
PR Review Comment: https://git.openjdk.org/jdk/pull/24864#discussion_r2059504832
PR Review Comment: https://git.openjdk.org/jdk/pull/24864#discussion_r2059499587
PR Review Comment: https://git.openjdk.org/jdk/pull/24864#discussion_r2059499808
PR Review Comment: https://git.openjdk.org/jdk/pull/24864#discussion_r2059444188
PR Review Comment: https://git.openjdk.org/jdk/pull/24864#discussion_r2059502886
PR Review Comment: https://git.openjdk.org/jdk/pull/24864#discussion_r2059503902
PR Review Comment: https://git.openjdk.org/jdk/pull/24864#discussion_r2059447895

From duke at openjdk.org  Sat Apr 26 04:04:30 2025
From: duke at openjdk.org (Hendrik Schick)
Date: Sat, 26 Apr 2025 04:04:30 GMT
Subject: RFR: 8355636: Speed =?UTF-8?B?4oCL4oCLdXA=?=
 Throwable::printStackTrace by reducing object allocation
In-Reply-To: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
References: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
Message-ID: 

On Fri, 25 Apr 2025 01:36:50 GMT, Shaojin Wen  wrote:

> In the Throwable::printStackTrace method, StringBuilder is created multiple times to build String. By sharing StringBuilder to build String, object allocation and copying are reduced.
> 
> In the scenario without suppressed and ourCause, unused IdentityHashMap is not created.
> 
> Through these optimizations, the performance of `new Exception().printStackTrace()` can be improved by about 10%.

src/java.base/share/classes/java/lang/Throwable.java line 712:

> 710: 
> 711:                 // Print cause, if any
> 712: 

Suggestion:

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24864#discussion_r2059833273

From swen at openjdk.org  Sat Apr 26 04:04:31 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 26 Apr 2025 04:04:31 GMT
Subject: RFR: 8355636: Speed =?UTF-8?B?4oCL4oCLdXA=?=
 Throwable::printStackTrace by reducing object allocation
In-Reply-To: 
References: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
 
Message-ID: 

On Fri, 25 Apr 2025 03:16:09 GMT, Chen Liang  wrote:

>> In the Throwable::printStackTrace method, StringBuilder is created multiple times to build String. By sharing StringBuilder to build String, object allocation and copying are reduced.
>> 
>> In the scenario without suppressed and ourCause, unused IdentityHashMap is not created.
>> 
>> Through these optimizations, the performance of `new Exception().printStackTrace()` can be improved by about 10%.
>
> src/java.base/share/classes/java/lang/Throwable.java line 749:
> 
>> 747:             // Print suppressed exceptions, if any
>> 748:             for (Throwable se : getSuppressed())
>> 749:                 se.printEnclosedStackTrace(s, trace, SUPPRESSED_CAPTION,
> 
> Shouldn't SUPPRESSED_CAPTION be added a prefix?
> 
> I think we should revert the `prefixCaption` argument change; you should add a line `String prefixCaption = prefix.concat(caption);` instead.

The reason for using prefixCaption is that javac can do constant folding when it is placed at the call site of the printStackTrace method.

> src/java.base/share/classes/java/lang/Throwable.java line 785:
> 
>> 783:             StackTraceElement[] trace,
>> 784:             int traceEnd,
>> 785:             int framesInCommon) {
> 
> You just need to pass `framesInCommon`, can calculate `int limit = trace.length - framesInCommon;` and then for the loop below, `for (int i = 0; i < limit; i++)` instead of using `traceEnd`

According to your suggestion, I removed the passing of framesInCommon, which can be calculated by `trace.length - 1 - traceEnd`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24864#discussion_r2059513887
PR Review Comment: https://git.openjdk.org/jdk/pull/24864#discussion_r2059515401

From liach at openjdk.org  Sat Apr 26 04:11:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 26 Apr 2025 04:11:59 GMT
Subject: RFR: 8328821: Map.of() derived view collection mutators should
 throw UnsupportedOperationException [v10]
In-Reply-To: <95_0h5qpY-WYbzFlfMqyETLmw3YkiBqh-MltS5-bpMU=.c7020e2e-e322-4b3e-b5d5-919304234e25@github.com>
References: 
 <95_0h5qpY-WYbzFlfMqyETLmw3YkiBqh-MltS5-bpMU=.c7020e2e-e322-4b3e-b5d5-919304234e25@github.com>
Message-ID: 

On Mon, 31 Mar 2025 18:30: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 with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - Update test/jdk/java/util/Collection/MOAT.java
>    
>    Co-authored-by: Chen Liang 
>  - Update copyright year
>    
>    and add the bug number to the modified test
>  - Update unmodifiable map javadoc
>  - Also throw UOE for mutators on keySet() and values()
>    
>    and add more test coverage to MOAT.
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - Check m.entrySet().hashCode() in MOAT
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/4d1de46c...d5c39132

I think our next steps are:
In early 26, if a corpus search proved no definitive incompatibility, integrate this change and post a message to quality-discuss. Same for #15614. If any incompatibility surfaces, we have sufficient time to rollback. What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2831820921

From jpai at openjdk.org  Sat Apr 26 04:37:45 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 26 Apr 2025 04:37:45 GMT
Subject: RFR: 8355636: Speed =?UTF-8?B?4oCL4oCLdXA=?=
 Throwable::printStackTrace by reducing object allocation
In-Reply-To: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
References: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
Message-ID: 

On Fri, 25 Apr 2025 01:36:50 GMT, Shaojin Wen  wrote:

> In the Throwable::printStackTrace method, StringBuilder is created multiple times to build String. By sharing StringBuilder to build String, object allocation and copying are reduced.
> 
> In the scenario without suppressed and ourCause, unused IdentityHashMap is not created.
> 
> Through these optimizations, the performance of `new Exception().printStackTrace()` can be improved by about 10%.

Other Reviewers may have a different opinion, mine is that this change should not be integrated.

Almost every piece of code in any project has a potential to be micro optimized for some arbitrary improvement, even the JDK project too. That doesn't mean that those changes should be done. I believe that this non-stop churn to the JDK code, code which has been around long enough without any practical issues, is not an improvement but a needless distraction.

This is not limited to just this PR. In general, I feel that the PRs that you have been opening and proposing as performance improvements or modernizing the code have this same general pattern. To me, it's starting to feel more and more like a cryptic coding contest. I believe the free use of Unsafe, SharedSecrets, closely handholding the Java code to please a particular current implementation of JIT compiler, the almost obsessive and never ending code changes related to micro optimizations techniques (constant folding, unchecked array access) in several of these PRs, just because it's a performance improvement, isn't a good thing for the maintainability of the JDK.

That's not the only thing though. In the past you have also been asked not to pursue changes like these at least not in the current form where you open a PR with no context, then create a JBS issue, again with no context in the description. The JDK project has contribution guidelines https://openjdk.org/guide/ and contributors have a role. Being a JDK committer, which you are, means they have extra responsibilities to making sure you respect and follow those guidelines and ensure the JDK code remains maintainable.

Specifically, for the changes you have been doing and proposing as optimizations like this one, I have not seen you raise a mailing list discussion (even when you have been previously asked to do so) checking whether it's OK to do such changes before raising the PR. I feel that this kind of continued behaviour is borderline abusing the JDK infrastructure and the review process. For the areas that I watch, several of the JBS issues that you file have no context, the PRs you create almost always have zero regression tests (including this one), the JBS issues don't have appropriate noreg labels, you almost never state what kind of testing you have done for your changes (running the JMH micro benchmark isn't enough). Opening a PR and then pushing reviewers to tell you why the change shouldn't be done and what's the alternate way to do that change isn't a productive way to contribute. While at it, just to be clear, this doesn't mean you change your workflow to creating a mailing list disc
 ussion, then going ahead and opening a PR/JBS issue. If you do create a mailing list discussion and don't see any response to it, please consider it a sign that there may not be interest in the change.

Some times we do integrate similar changes without pushing back too much and I believe that's reasonable. But continued and never ending churn like this is not good. I realize this comment is harsh but this isn't the first time some of the reviewers have advised you not to contribute in this manner. In general, I request you to reconsider the way you contribute to the project.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24864#issuecomment-2831834947

From jwaters at openjdk.org  Sat Apr 26 04:49:55 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 26 Apr 2025 04:49:55 GMT
Subject: RFR: 8355573: Remove kludge_c++11.h from jpackage code
Message-ID: 

kludge_c++11.h was introduced to work around older C++ versions not having access to C++ utilities like std::unique_ptr. Since we are already on C++14 (And hopefully will get C++17 soon) this workaround can be removed from jpackage code.

-------------

Commit messages:
 - Include memory header in MsiUtils.h
 - Delete src/jdk.jpackage/share/native/common/kludge_c++11.h
 - Remove kludge_c++11.h from CfgFile.cpp
 - Remove kludge_c++11.h from app.cpp
 - Remove kludge_c++11.h from LinuxLauncherLib.cpp
 - Remove kludge_c++11.h from StringProcessing.cpp
 - Remove kludge_c++11.h from Dll.h
 - Remove kludge_c++11.h from PackageFile.cpp

Changes: https://git.openjdk.org/jdk/pull/24868/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24868&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355573
  Stats: 183 lines in 8 files changed: 1 ins; 182 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24868.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24868/head:pull/24868

PR: https://git.openjdk.org/jdk/pull/24868

From swen at openjdk.org  Sat Apr 26 04:52:58 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 26 Apr 2025 04:52:58 GMT
Subject: Withdrawn: 8355301: Simplify Throwable::printStackTrace by using
 record
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Apr 2025 11:06:17 GMT, Shaojin Wen  wrote:

> The current Throwable::printStackTrace implementation uses three inner classes PrintStreamOrWriter/WrappedPrintStream/WrappedPrintWriter. We can introduce a static method println to replace these three embedded classes.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24795

From eirbjo at openjdk.org  Sat Apr 26 06:24:50 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 26 Apr 2025 06:24:50 GMT
Subject: RFR: 8355636: Speed =?UTF-8?B?4oCL4oCLdXA=?=
 Throwable::printStackTrace by reducing object allocation
In-Reply-To: 
References: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
 
Message-ID: 

On Sat, 26 Apr 2025 04:34:58 GMT, Jaikiran Pai  wrote:

> Other Reviewers may have a different opinion, mine is that this change should not be integrated.

Thank you @jaikiran for taking on the unglamorous task of writing this note.

> Almost every piece of code in any project has a potential to be micro optimized for some arbitrary improvement, even the JDK project too. That doesn't mean that those changes should be done. 

Faster != better.

The Magic of Java is not that 1% of developers can write clever, lock-free, allocation free, low-level, hand-optimized code. 

What's magic is that you can put any random 80% developer on a boring e-commerce project, switch them out over years or even decades and still have a reasonably maintainable (and performant!) code base 15 years later.  This is the Ethos of the Java platform to me, not that it helps you win the The One Billion Row Challenge. 

Put too many 1% developers on a Java project and they will soon get bored and start inventing clever problems for which they have even more clever solutions. But clever != maintainable. Maintainable code is straightforward, stupid and obvious.

> I believe that this non-stop churn to the JDK code, code which has been around long enough without any practical issues, is not an improvement but a needless distraction.

Changes should be justified and solve a real-world problem. Solving the problem should have clear benefits which outweigh the cost of the review process and the cost of any future increase in maintainability burden over decades. 

My first contribution to OpenJDK was performance related, so has many of my later contributions. I have also received reviewer pushback when my micro optimizations seemed inconsequential, affected long term maintainabiliy in negative ways or made changes too tricky or laborsome to review. So I tried to adapt, become more self-critical towards which problems I was solving and I even started looking into other kinds of problems, like fixing correctness bugs, improving test coverage.

The review process is not for free. It's important to actually listen to what reviewers are saying. When they are not saying much, that's also a signal. When getting reviewer pushback for a change, I often find it more productive to just withdraw the change and find something else to work on, rather than arguing against the reviewers or changing the goal of the PR just to push it through.

Faster != better.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24864#issuecomment-2831897022

From swen at openjdk.org  Sat Apr 26 06:53:45 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 26 Apr 2025 06:53:45 GMT
Subject: RFR: 8355636: Speed =?UTF-8?B?4oCL4oCLdXA=?=
 Throwable::printStackTrace by reducing object allocation [v2]
In-Reply-To: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
References: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
Message-ID: 

> In the Throwable::printStackTrace method, StringBuilder is created multiple times to build String. By sharing StringBuilder to build String, object allocation and copying are reduced.
> 
> In the scenario without suppressed and ourCause, unused IdentityHashMap is not created.
> 
> Through these optimizations, the performance of `new Exception().printStackTrace()` can be improved by about 10%.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  add testcase

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24864/files
  - new: https://git.openjdk.org/jdk/pull/24864/files/a68c6932..2483992f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24864&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24864&range=00-01

  Stats: 257 lines in 1 file changed: 257 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24864.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24864/head:pull/24864

PR: https://git.openjdk.org/jdk/pull/24864

From swen at openjdk.org  Sat Apr 26 07:01:46 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 26 Apr 2025 07:01:46 GMT
Subject: RFR: 8355636: Speed =?UTF-8?B?4oCL4oCLdXA=?=
 Throwable::printStackTrace by reducing object allocation [v3]
In-Reply-To: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
References: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
Message-ID: 

> In the Throwable::printStackTrace method, StringBuilder is created multiple times to build String. By sharing StringBuilder to build String, object allocation and copying are reduced.
> 
> In the scenario without suppressed and ourCause, unused IdentityHashMap is not created.
> 
> Through these optimizations, the performance of `new Exception().printStackTrace()` can be improved by about 10%.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix code style

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24864/files
  - new: https://git.openjdk.org/jdk/pull/24864/files/2483992f..3d7a921a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24864&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24864&range=01-02

  Stats: 44 lines in 1 file changed: 0 ins; 3 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/24864.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24864/head:pull/24864

PR: https://git.openjdk.org/jdk/pull/24864

From swen at openjdk.org  Sat Apr 26 07:30:45 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 26 Apr 2025 07:30:45 GMT
Subject: RFR: 8355636: Speed =?UTF-8?B?4oCL4oCLdXA=?=
 Throwable::printStackTrace by reducing object allocation [v3]
In-Reply-To: 
References: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
 
Message-ID: 

On Sat, 26 Apr 2025 07:01:46 GMT, Shaojin Wen  wrote:

>> In the Throwable::printStackTrace method, StringBuilder is created multiple times to build String. By sharing StringBuilder to build String, object allocation and copying are reduced.
>> 
>> In the scenario without suppressed and ourCause, unused IdentityHashMap is not created.
>> 
>> Through these optimizations, the performance of `new Exception().printStackTrace()` can be improved by about 10%.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix code style

This PR has added a testcase.

This patch is safe and does not use Unsafe and SharedSecrets. This optimization is to share StringBuilder as Line Buffer when printStackTrace prints each line.

The changes in this PR are actually not many, and the logic has not changed. The goal of the optimization is also very clear, which is to make the program perform better when a large number of exceptions are thrown when an error occurs. This is a very typical scenario.

This optimization has taken compatibility into consideration to ensure that the behavior is the same as before. For example, StackTraceElement.toString remains unchanged and calls PrintStreamOrWriter::println(Object) instead of PrintStreamOrWriter::println(String).

I hope the discussion can return to this PR and discuss specific technical points instead of philosophy. For example, discuss which line of code is bad, unsafe, not maintainable, and has a better way to write it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24864#issuecomment-2831929122

From hgreule at openjdk.org  Sat Apr 26 07:48:45 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Sat, 26 Apr 2025 07:48:45 GMT
Subject: RFR: 8355636: Speed =?UTF-8?B?4oCL4oCLdXA=?=
 Throwable::printStackTrace by reducing object allocation [v3]
In-Reply-To: 
References: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
 
 
Message-ID: 

On Sat, 26 Apr 2025 07:28:03 GMT, Shaojin Wen  wrote:

> The goal of the optimization is also very clear, which is to make the program perform better when a large number of exceptions are thrown when an error occurs. This is a very typical scenario.

But that's not what's happening here. While *throwing* exceptions **can** be performance-sensitive, *printing* exceptions is far less important. I'm not convinced that printing exceptions is a very typical scenario.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24864#issuecomment-2831938869

From eirbjo at openjdk.org  Sat Apr 26 08:25:47 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 26 Apr 2025 08:25:47 GMT
Subject: RFR: 8355636: Speed =?UTF-8?B?4oCL4oCLdXA=?=
 Throwable::printStackTrace by reducing object allocation [v3]
In-Reply-To: 
References: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
 
 
Message-ID: <8ebyJdE-KOpnY4-G2ym8dDBBySptaG45YGgHFt3heaQ=.c96e6805-ffbb-4d22-9ddc-9a5b80d342e6@github.com>

On Sat, 26 Apr 2025 07:28:03 GMT, Shaojin Wen  wrote:

> I hope the discussion can return to this PR and discuss specific technical points instead of philosophy.

Discussing technical points about code in this PR seems premature at this point.

Reviewers have raised concerns about the larger picture of usefulness vs. cost of this change and also about the even larger picture which is your stream of similar optimization PRs. I think you need to address those concerns before trying to push this PR forward via more code changes.

> The changes in this PR are actually not many, and the logic has not changed

That's your claim and could would well be true. But reviewers will still need to verify this independently, they cannot just take your word for it. If that was the case, why would we need a review process at all? The cost of reviewing this PR is still significant.
 
I think you should either just withdraw this PR or engage in meaningful communication where you socialize the problem and your solution first. Only when you get a consensus that the problem is worth pursuing should work on this PR continue. 

> This PR has added a testcase.

The concerns raised seems more related to to process, socialization and communication. Responding to that by adding a test case seems counterproductive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24864#issuecomment-2831956561

From eirbjo at openjdk.org  Sat Apr 26 08:44:47 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 26 Apr 2025 08:44:47 GMT
Subject: RFR: 8355636: Speed =?UTF-8?B?4oCL4oCLdXA=?=
 Throwable::printStackTrace by reducing object allocation [v3]
In-Reply-To: 
References: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
 
Message-ID: 

On Sat, 26 Apr 2025 07:01:46 GMT, Shaojin Wen  wrote:

>> In the Throwable::printStackTrace method, StringBuilder is created multiple times to build String. By sharing StringBuilder to build String, object allocation and copying are reduced.
>> 
>> In the scenario without suppressed and ourCause, unused IdentityHashMap is not created.
>> 
>> Through these optimizations, the performance of `new Exception().printStackTrace()` can be improved by about 10%.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix code style

> But that's not what's happening here. While _throwing_ exceptions **can** be performance-sensitive, _printing_ exceptions is far less important. I'm not convinced that printing exceptions is a very typical scenario.

Even if that was the case, for any printing to be useful to any human beeing it would require IO to disk, database or have some form of external effect rather than just printing it to a NullOutputStream which is what the benchmark here does. Factor IO into the equation and my guess is those 10% are a lot closer to zero. 

Doing the wrong thing faster is not the way to go.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24864#issuecomment-2831966169

From swen at openjdk.org  Sat Apr 26 09:21:32 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 26 Apr 2025 09:21:32 GMT
Subject: RFR: 8355636: Speed =?UTF-8?B?4oCL4oCLdXA=?=
 Throwable::printStackTrace by reducing object allocation [v4]
In-Reply-To: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
References: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
Message-ID: 

> In the Throwable::printStackTrace method, StringBuilder is created multiple times to build String. By sharing StringBuilder to build String, object allocation and copying are reduced.
> 
> In the scenario without suppressed and ourCause, unused IdentityHashMap is not created.
> 
> Through these optimizations, the performance of `new Exception().printStackTrace()` can be improved by about 10%.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix benchmark, use FileOutputStream

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24864/files
  - new: https://git.openjdk.org/jdk/pull/24864/files/3d7a921a..e40726c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24864&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24864&range=02-03

  Stats: 9 lines in 1 file changed: 2 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24864.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24864/head:pull/24864

PR: https://git.openjdk.org/jdk/pull/24864

From swen at openjdk.org  Sat Apr 26 09:21:33 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 26 Apr 2025 09:21:33 GMT
Subject: RFR: 8355636: Speed =?UTF-8?B?4oCL4oCLdXA=?=
 Throwable::printStackTrace by reducing object allocation [v3]
In-Reply-To: 
References: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
 
 
Message-ID: 

On Sat, 26 Apr 2025 08:41:28 GMT, Eirik Bj?rsn?s  wrote:

> Even if that was the case, for any printing to be useful to any human beeing it would require IO to disk, database or have some form of external effect rather than just printing it to a NullOutputStream which is what the benchmark here does. Factor IO into the equation and my guess is those 10% are a lot closer to zero.
> 
> Doing the wrong thing faster is not the way to go.

![image](https://github.com/user-attachments/assets/917e0e84-7a36-4c35-80fd-903cf2268859)

When the input is incorrect, an exception will be thrown. For example, the parameter check Integer.parseInt. Another example is that the index passed in is incorrect, which leads to an array or ArrayList boundary check exception. These are not the normal paths we expect. When abnormal external calls occur, such as OpenAPI, Java Web backend code processes the json input by the front end, exceptions will often occur.

In many framework codes, when an exception occurs, the Log library will be used to print the exception to make the problem easier to diagnose, rather than ignoring the exception. At this time, printStackTrace needs to pay attention to performance issues.


In the entire process of throwing an exception and PrintStackTrace, Throwable::getOutStackeTrace and Throwable::fillStackTrace take up about 1/3 of the time, and more time is consumed in the printStackTrace method itself, so we need to optimize this.

@eirbjo found that using NullOutputStream in performance testing is not good, so I changed it to FileOutputStream.

Changing from NullOutputStream to FileOutpuStream, the performance improvement increased from 11% to 5%~9%. Because PrintStream uses BufferedWriter, it will cache a certain amount of data before flushing, so using FileOutpuStream will affect performance, but not much.

Here are the performance numbers on the MacBook Pro M1 Max

git remote addd wenshao https://github.com/wenshao/jdk
git fetch wenshao

# baseline
git checkout 53873fb2178add153d1a6edb932a915fc1c63dc6
make test TEST="micro:java.lang.Throwables"

# current
git checkout e40726c1c0dfcbc284010b187e3203617afef519
make test TEST="micro:java.lang.Throwables"




# baseline 53873fb2178add153d1a6edb932a915fc1c63dc6
-Benchmark                           Mode  Cnt       Score      Error  Units
-Throwables.printEnclosedStackTrace  avgt   15   69365.403 ? 2026.607  ns/op
-Throwables.printStackTrace          avgt   15  109287.777 ? 5074.292  ns/op

# current e40726c1c0dfcbc284010b187e3203617afef519
+Benchmark                           Mode  Cnt       Score      Error  Units
+Throwables.printEnclosedStackTrace  avgt   15   65948.100 ? 3869.844  ns/op +9.99%
+Throwables.printStackTrace          avgt   15  103575.966 ? 4825.130  ns/op +5.51%

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24864#issuecomment-2831985668

From kbarrett at openjdk.org  Sat Apr 26 09:24:46 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 26 Apr 2025 09:24:46 GMT
Subject: RFR: 8355632: WhiteBox.waitForReferenceProcessing() fails assert
 for return type
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Apr 2025 23:37:13 GMT, Brent Christian  wrote:

> The newly-added `WhiteBox.waitForReferenceProcessing()` (see [8305186](https://bugs.openjdk.org/browse/JDK-8305186)) always fails with assertions enabled.
> I've updated the assertion, and also added the test I used locally to test the new method (just not with assertions enabled, apparently.)

Changes requested by kbarrett (Reviewer).

test/hotspot/jtreg/vmTestbase/gc/gctests/ReferencesGC/WaitForRefProTest.java line 1:

> 1: /*

Wrong place for this test. vmTestbase is old tests, converted from an old testing infrastructure.
See the readme here:  https://github.com/openjdk/jdk/tree/master/test/hotspot/jtreg/vmTestbase
In particular, at the bottom of that page: "New tests must *not* be added into this directory."

This new test belongs in `test/lib-test/jdk/test/whitebox/`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24892#pullrequestreview-2795859193
PR Review Comment: https://git.openjdk.org/jdk/pull/24892#discussion_r2061239344

From kbarrett at openjdk.org  Sat Apr 26 09:24:46 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 26 Apr 2025 09:24:46 GMT
Subject: RFR: 8355632: WhiteBox.waitForReferenceProcessing() fails assert
 for return type
In-Reply-To: 
References: 
 
Message-ID: <7uq7PHOFSjfI7edckxGfoYsHjJJ9ba-VkV1t7nCIriE=.7a92c288-b3b6-482d-97c4-79552cd43c95@github.com>

On Sat, 26 Apr 2025 09:18:35 GMT, Kim Barrett  wrote:

>> The newly-added `WhiteBox.waitForReferenceProcessing()` (see [8305186](https://bugs.openjdk.org/browse/JDK-8305186)) always fails with assertions enabled.
>> I've updated the assertion, and also added the test I used locally to test the new method (just not with assertions enabled, apparently.)
>
> test/hotspot/jtreg/vmTestbase/gc/gctests/ReferencesGC/WaitForRefProTest.java line 1:
> 
>> 1: /*
> 
> Wrong place for this test. vmTestbase is old tests, converted from an old testing infrastructure.
> See the readme here:  https://github.com/openjdk/jdk/tree/master/test/hotspot/jtreg/vmTestbase
> In particular, at the bottom of that page: "New tests must *not* be added into this directory."
> 
> This new test belongs in `test/lib-test/jdk/test/whitebox/`.

Also, s/Pro/Proc/ in the name of the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24892#discussion_r2061240134

From swen at openjdk.org  Sat Apr 26 09:47:46 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 26 Apr 2025 09:47:46 GMT
Subject: RFR: 8355636: Speed =?UTF-8?B?4oCL4oCLdXA=?=
 Throwable::printStackTrace by reducing object allocation [v4]
In-Reply-To: 
References: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
 
Message-ID: 

On Sat, 26 Apr 2025 09:21:32 GMT, Shaojin Wen  wrote:

>> In the Throwable::printStackTrace method, StringBuilder is created multiple times to build String. By sharing StringBuilder to build String, object allocation and copying are reduced.
>> 
>> In the scenario without suppressed and ourCause, unused IdentityHashMap is not created.
>> 
>> Through these optimizations, the performance of `new Exception().printStackTrace()` can be improved by about 10%.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix benchmark, use FileOutputStream

Below are the performance numbers on Aliyun ECS c8a (x64 AMD CPU EPYC? Genoa + Linux), The results show that writing FileOutputStream on the cloud host still has a performance improvement of 5% to 7%.


git remote addd wenshao https://github.com/wenshao/jdk

# baseline
git checkout 53873fb2178add153d1a6edb932a915fc1c63dc6
make test TEST="micro:java.lang.Throwables"

# current
git checkout e40726c1c0dfcbc284010b187e3203617afef519
make test TEST="micro:java.lang.Throwables"




# baseline 53873fb2178add153d1a6edb932a915fc1c63dc6
-Benchmark                           Mode  Cnt      Score     Error  Units
-Throwables.printEnclosedStackTrace  avgt   15  60816.939 ? 556.481  ns/op
-Throwables.printStackTrace          avgt   15  98745.841 ? 680.632  ns/op

# current e40726c1c0dfcbc284010b187e3203617afef519
Benchmark                           Mode  Cnt      Score      Error  Units
+Throwables.printEnclosedStackTrace  avgt   15  56417.649 ? 2310.963  ns/op +7.79%
+Throwables.printStackTrace          avgt   15  93265.294 ? 3014.466  ns/op +5.87%

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24864#issuecomment-2831999128

From aph at openjdk.org  Sat Apr 26 10:06:44 2025
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 26 Apr 2025 10:06:44 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms
In-Reply-To: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
Message-ID: 

On Sun, 6 Apr 2025 03:48:22 GMT, Mohamed Issa  wrote:

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.cbrt() using libm.
> 
> The results of all tests posted below were captured with an [Intel? Xeon 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) using [OpenJDK v25-b15](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B15) as the baseline version.
> 
> For performance data collected with the built in **cbrt** micro-benchmark, see the table below. Each result is the mean of 8 individual runs. Overall, the intrinsic provides a performance uplift of 41%.
> 
> | Benchmark        | Throughput with baseline (op/s) | Throughput with intrinsic (op/s) | Speedup |
> | :----------------: | :----------------------------------: | :----------------------------------: | :---------: |
> | MathBench.cbrt | 148242                                        | 209122                                        | 1.41x       |
> 
> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed with the changes.

What are the monotonicity and accuracy results for this approximation? Is it correctly rounded or faithfully rounded?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24470#issuecomment-2832008455

From aph at openjdk.org  Sat Apr 26 11:04:46 2025
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 26 Apr 2025 11:04:46 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms
In-Reply-To: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
Message-ID: <1pQ0qy9CEbpJ6Qd6VRuHGrM5aObN7MTOrIgOIliNWvQ=.b0babb5e-bf97-46a0-8800-72d55e0b592b@github.com>

On Sun, 6 Apr 2025 03:48:22 GMT, Mohamed Issa  wrote:

> the built in **cbrt** micro-benchmark

How should we run that benchmark? Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24470#issuecomment-2832035668

From swen at openjdk.org  Sat Apr 26 11:30:30 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 26 Apr 2025 11:30:30 GMT
Subject: RFR: 8355636: Speed =?UTF-8?B?4oCL4oCLdXA=?=
 Throwable::printStackTrace by reducing object allocation [v5]
In-Reply-To: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
References: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
Message-ID: 

> In the Throwable::printStackTrace method, StringBuilder is created multiple times to build String. By sharing StringBuilder to build String, object allocation and copying are reduced.
> 
> In the scenario without suppressed and ourCause, unused IdentityHashMap is not created.
> 
> Through these optimizations, the performance of `new Exception().printStackTrace()` can be improved by about 10%.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix windows lineSeparator

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24864/files
  - new: https://git.openjdk.org/jdk/pull/24864/files/e40726c1..d5e9e413

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24864&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24864&range=03-04

  Stats: 42 lines in 1 file changed: 2 ins; 0 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/24864.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24864/head:pull/24864

PR: https://git.openjdk.org/jdk/pull/24864

From duke at openjdk.org  Sat Apr 26 13:19:59 2025
From: duke at openjdk.org (Oliver Kopp)
Date: Sat, 26 Apr 2025 13:19:59 GMT
Subject: RFR: 8319457: Update jpackage to support WiX v4 and v5 on Windows
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: <9yH-cW3pckTJWtokFbmYu6NOtZ7lTfLHJSUmEFMQows=.52fe3bca-be29-4888-9a50-617cdec5c8cb@github.com>

On Thu, 6 Jun 2024 12:41:17 GMT, Alexey Semenyuk  wrote:

> jpackage allows override of main WiX source file (main.wxs), do you know what will happen if user will add main.wxs with format features available only in WiX 5 and will have WiX 5 toolkit installed?

@alexeysemenyukoracle Related question: Generation of `main.wxs` was moved from `prepareMainProjectFile` to `buildMSI`. This breaks [our patches to](https://github.com/JabRef/jabref/blob/95dcbe64659ced52627e012f2b6b5a60a9bb21b1/buildres/windows/JabRef-post-image.wsf#L18) `main.wxs` (which used to work for 6+ years now) 

Quoting https://docs.oracle.com/en/java/javase/24/jpackage/override-jpackage-resources.html#GUID-62412365-821D-4736-A20D-70F2D47136D8, the `post-image` script is executed before `buildMSI` (which is right).

> Custom script that is **executed after the application image** is created and **before the MSI installer is built** for both .msi and .exe packages. No default script is provided. 

I would expect that all files are available before the "Post-image script" are available - and not generated **after** any **Post**-image script is run.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19318#issuecomment-2832153958

From liach at openjdk.org  Sat Apr 26 15:35:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 26 Apr 2025 15:35:48 GMT
Subject: RFR: 8077587: BigInteger Roots [v19]
In-Reply-To: 
References: 
 
 
 
 <8Cd065O2M59QfLt9yaOtn61ZEfB3V-oy1ppTn1Ho-pQ=.6d9ee1ab-bdf4-4619-aacf-68d7927635fd@github.com>
 
Message-ID: 

On Thu, 24 Apr 2025 20:18:42 GMT, fabioromano1  wrote:

>> @fabioromano1 I just had a cursory glance at this PR.
>> 
>> AFAIU, there are two main contributions here:
>> 
>> - Performance enhancements in `pow()`, which is of general interest and does not require submitting a [CSR](https://wiki.openjdk.org/display/csr/Main).
>> - Introduction of a new public API point for the _n_-th root, which would require a CSR.
>> 
>> It's important to understand that if we add public API points, there must be some evidence and consensus about their general usefulness and demand for them. Every addition is a commitment for this community in terms of code maintenance, reviews, testing, documentation, so they should be evaluated with this perspective in mind.
>> 
>> In this case, I feel that the proposed _n_-th root might not be among the top priority API points to add to `BigInteger`. Perhaps the overall plan is to use this method to implement a _n_-th root in `BigDecimal` in some followup PR, but this is not stated here.
>> 
>> Anyway, a [preliminary discussion](https://openjdk.org/guide/#socialize-your-change) about the proposal should take place on the mailing list, _before_ submitting the PR and invest too much work on the code.
>> 
>> To make progress here, I suggest to split this PR in two, if technically possible:
>> 
>> - One for the enhancements in `pow`, with JMH results before/after.
>> - Another PR for the proposed _n_-th root.
>> 
>> Thanks
>
>> * Performance enhancements in `pow()`, which is of general interest and does not require submitting a [CSR](https://wiki.openjdk.org/display/csr/Main).
> 
> @rgiulietti Yes, but here, the primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
> 
>> To make progress here, I suggest to split this PR in two, if technically possible:
>> 
>> * One for the enhancements in `pow`, with JMH results before/after.
>> * Another PR for the proposed _n_-th root.
> 
> I'm not very sure if it is technically possible, because both `pow()` and `nthRoot()` requires the computation of a power of a long, so that code has to be shared by both methods, and so a supposed PR for `nthRoot()` would require that method.

@fabioromano1 In this case, we will add the common code to pow() enhancement - since it does not require a CSR, it is most likely to be integrated before nthRoot() addition, and nthRoot() can be a dependent PR on the pow() enhancement (i.e. you create a new branch against `pr/#` branch in openjdk and open pr, such a pr is a dependent)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2832321224

From duke at openjdk.org  Sat Apr 26 15:42:09 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 26 Apr 2025 15:42:09 GMT
Subject: RFR: 8077587: BigInteger Roots [v32]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for `BigInteger`s using Newton method and optimizes `BigInteger.pow(int)` method.

fabioromano1 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 38 additional commits since the last revision:

 - Merge branch 'openjdk:master' into BigInteger-nth-root
 - Optimized nth root iteration loop
 - Systematization of special cases in BigInteger.pow(int)
 - Some optimizations
 - Optimized repeated squaring trick using cache for powers
 - Optimized BigInteger.pow(int) for single-word values
 - An optimization
 - Format code
 - Optimized computation of nth root's remainder
 - Delete useless folder
 - ... and 28 more: https://git.openjdk.org/jdk/compare/b8bb1cbf...f9bfd22c

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/23914e8a..f9bfd22c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=30-31

  Stats: 35561 lines in 1017 files changed: 26806 ins; 6281 del; 2474 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From swen at openjdk.org  Sat Apr 26 16:13:35 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 26 Apr 2025 16:13:35 GMT
Subject: RFR: 8355636: Reuse StringBuilder in printStackTrace [v6]
In-Reply-To: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
References: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
Message-ID: 

> In the Throwable::printStackTrace method, StringBuilder is created multiple times to build String. By sharing StringBuilder to build String, object allocation and copying are reduced.
> 
> In the scenario without suppressed and ourCause, unused IdentityHashMap is not created.
> 
> Through these optimizations, the performance of `new Exception().printStackTrace()` can be improved by about 10%.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix windows build error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24864/files
  - new: https://git.openjdk.org/jdk/pull/24864/files/d5e9e413..6160f403

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24864&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24864&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24864.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24864/head:pull/24864

PR: https://git.openjdk.org/jdk/pull/24864

From duke at openjdk.org  Sat Apr 26 16:20:21 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 26 Apr 2025 16:20:21 GMT
Subject: RFR: 8077587: BigInteger Roots
Message-ID: 

This PR implements nth root computation for BigIntegers using Newton method. This PR is dependent by this [PR](https://github.com/openjdk/jdk/pull/24690).

-------------

Commit messages:
 - Merge branch 'openjdk:master' into BigInteger-nth-root
 - Optimized nth root iteration loop
 - Systematization of special cases in BigInteger.pow(int)
 - Some optimizations
 - Optimized repeated squaring trick using cache for powers
 - Optimized BigInteger.pow(int) for single-word values
 - An optimization
 - Format code
 - Optimized computation of nth root's remainder
 - Delete useless folder
 - ... and 28 more: https://git.openjdk.org/jdk/compare/21b0f5ea...f9bfd22c

Changes: https://git.openjdk.org/jdk/pull/24898/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8077587
  Stats: 377 lines in 2 files changed: 343 ins; 15 del; 19 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 duke at openjdk.org  Sat Apr 26 16:28:27 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 26 Apr 2025 16:28:27 GMT
Subject: RFR: 8077587: BigInteger Roots [v33]
In-Reply-To: 
References: 
Message-ID: 

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Moved nth-root implementation to a dependent PR

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/f9bfd22c..7ceae871

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=31-32

  Stats: 190 lines in 2 files changed: 0 ins; 190 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From duke at openjdk.org  Sat Apr 26 16:44:26 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 26 Apr 2025 16:44:26 GMT
Subject: RFR: 4837946: Faster multiplication and exponentiation of large
 integers [v34]
In-Reply-To: 
References: 
Message-ID: 

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Removed  method used by nth-root

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/7ceae871..cb61ddc1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=32-33

  Stats: 21 lines in 1 file changed: 0 ins; 21 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From duke at openjdk.org  Sat Apr 26 17:07:33 2025
From: duke at openjdk.org (Markus KARG)
Date: Sat, 26 Apr 2025 17:07:33 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v8]
In-Reply-To: 
References: 
Message-ID: <1s3MwTXb7v_7WWORxAL4WXOlbMOnpCkt8kbjc613-UM=.a81c62cc-4cc5-4714-8d3b-a63f0b9e092d@github.com>

> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
> 
> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
> 
> To ensure quality...
> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.'

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21730/files
  - new: https://git.openjdk.org/jdk/pull/21730/files/cb2a2efb..47fbca7e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21730&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21730&range=06-07

  Stats: 63 lines in 4 files changed: 0 ins; 61 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21730/head:pull/21730

PR: https://git.openjdk.org/jdk/pull/21730

From liach at openjdk.org  Sat Apr 26 17:07:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 26 Apr 2025 17:07:53 GMT
Subject: RFR: 4837946: Faster multiplication and exponentiation of large
 integers [v34]
In-Reply-To: 
References: 
 
Message-ID: <4W074o10ZVJY_V5RprXaHimoF5WWHxIQzP9gF210evE=.a9f67d2c-6a4c-4943-9ed7-780524b6b2e5@github.com>

On Sat, 26 Apr 2025 16:44:26 GMT, fabioromano1  wrote:

>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed  method used by nth-root

src/java.base/share/classes/java/math/BigInteger.java line 2717:

> 2715:         int blockLen;
> 2716:         for (int nLen = Integer.SIZE - nZeros; nLen > 0; nLen -= blockLen) {
> 2717:             blockLen = maxExpLen < nLen ? maxExpLen : nLen;

`blockLen` can be defined in the loop like:

int blockLen = Math.min(maxExpLen, nLen);

src/java.base/share/classes/java/math/BigInteger.java line 2728:

> 2726:             if (exp > 0) {
> 2727:                 BigInteger xToExp = powerCache[exp];
> 2728:                 if (xToExp == null) {

Can we extract the cache computation logic into a new method for clarity? Huge methods hamper readability.

This use site will look like:

if (exp > 0) {
    BigInteger xToExp = powerCache[exp];
    if (xToExp == null) {
        xToExp = computePower(powerCache, x, exp, maxExp);
    }
}


`computePower` stores entries to `powerCache` whenever it computed something to allow  reuse.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2061491416
PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2061492295

From liach at openjdk.org  Sat Apr 26 17:10:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 26 Apr 2025 17:10:47 GMT
Subject: RFR: 4837946: Faster multiplication and exponentiation of large
 integers [v34]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 26 Apr 2025 16:44:26 GMT, fabioromano1  wrote:

>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed  method used by nth-root

src/java.base/share/classes/java/math/BigInteger.java line 2707:

> 2705:         // such that x^e fits into a double. If e <= 2, we won't use fp arithmetic.
> 2706:         // This allows to use fp arithmetic where possible.
> 2707:         final int maxExp = Math.max(2, Double.PRECISION / bitLengthForInt(x));

We should link this 2 to the logic to xToExpAdj below - with comments on both sites.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2061492878

From liach at openjdk.org  Sat Apr 26 17:21:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 26 Apr 2025 17:21:47 GMT
Subject: RFR: 4837946: Faster multiplication and exponentiation of large
 integers [v34]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 26 Apr 2025 16:44:26 GMT, fabioromano1  wrote:

>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed  method used by nth-root

src/java.base/share/classes/java/math/BigInteger.java line 2721:

> 2719:             if (!pow.equals(ONE)) {
> 2720:                 for (int i = 0; i < blockLen; i++)
> 2721:                     pow = pow.multiply(pow);

Majority of the time we have `blockLen == maxExpLen`. We should cache that pow-to-maxExpLen result too, if we have `maxExpLen >= nLen` initially. Maybe also calculate power-to-`nLen % maxExpLen` as that will be used in the final round of the loop.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2061496813

From liach at openjdk.org  Sat Apr 26 17:24:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 26 Apr 2025 17:24:46 GMT
Subject: RFR: 4837946: Faster multiplication and exponentiation of large
 integers [v34]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sat, 26 Apr 2025 17:19:30 GMT, Chen Liang  wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed  method used by nth-root
>
> src/java.base/share/classes/java/math/BigInteger.java line 2721:
> 
>> 2719:             if (!pow.equals(ONE)) {
>> 2720:                 for (int i = 0; i < blockLen; i++)
>> 2721:                     pow = pow.multiply(pow);
> 
> Majority of the time we have `blockLen == maxExpLen`. We should cache that pow-to-maxExpLen result too, if we have `maxExpLen >= nLen` initially. Maybe also calculate power-to-`nLen % maxExpLen` as that will be used in the final round of the loop.

No, pow is always being modified, ignore this, my bad.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2061497718

From duke at openjdk.org  Sat Apr 26 17:50:47 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 26 Apr 2025 17:50:47 GMT
Subject: RFR: 4837946: Faster multiplication and exponentiation of large
 integers [v34]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Sat, 26 Apr 2025 17:22:09 GMT, Chen Liang  wrote:

>> src/java.base/share/classes/java/math/BigInteger.java line 2721:
>> 
>>> 2719:             if (!pow.equals(ONE)) {
>>> 2720:                 for (int i = 0; i < blockLen; i++)
>>> 2721:                     pow = pow.multiply(pow);
>> 
>> Majority of the time we have `blockLen == maxExpLen`. We should cache that pow-to-maxExpLen result too, if we have `maxExpLen >= nLen` initially. Maybe also calculate power-to-`nLen % maxExpLen` as that will be used in the final round of the loop.
>
> No, pow is always being modified, ignore this, my bad.

> Majority of the time we have `blockLen == maxExpLen`. We should cache that pow-to-maxExpLen result too, if we have `maxExpLen >= nLen` initially. Maybe also calculate power-to-`nLen % maxExpLen` as that will be used in the final round of the loop.

I don't get the point, since `pow` changes its value at every iteration and here the property of the "power of a power" is used, i.e. `pow^(2^n) == (((pow^2)^2)...)^2` `n` times to shift the exponent of the power, so I don't see how caching pow-to-maxExpLen would be useful.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2061511811

From nlisker at gmail.com  Sat Apr 26 18:55:23 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Sat, 26 Apr 2025 21:55:23 +0300
Subject: Casting gatherer
Message-ID: 

Hi,

instanceof has been refitted to include an auto-cast ("pattern matching on
instanceof"). Unfortunately, doing this as an intermediate operation on a
stream requires first to filter via instanceof and then map via a cast.
This is because

    x instanceof MyClass myClass

returns a boolean, not myClass.

I've asked for an easier way of doing it long ago directly on Stream and
was declined, but now with Gatherers I'm bringing this up again. I think it
would be reasonable to put such an operation in the Gatherers class. I
imagine that many Gatherer libraries, or utility classes, will include it
since it's a common operation, and having it in the JDK means that it'll be
done the best way possible (you can optimize where others can't, if
applicable here).

-- Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Sat Apr 26 19:11:01 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 26 Apr 2025 19:11:01 GMT
Subject: RFR: 4837946: Faster multiplication and exponentiation of large
 integers [v35]
In-Reply-To: 
References: 
Message-ID: <2Tg_EausewiyR5mEYtVgxoYKHwdc7PLKrf1QzxFzN4Q=.71d5ebb4-acee-42fb-94bb-d0754bddf951@github.com>

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Put power's computation in a stand-alone method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/cb61ddc1..10e122e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=33-34

  Stats: 137 lines in 1 file changed: 84 ins; 45 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From chen.l.liang at oracle.com  Sat Apr 26 19:12:36 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Sat, 26 Apr 2025 19:12:36 +0000
Subject: Casting gatherer
In-Reply-To: 
References: 
Message-ID: 

Hi Nir, I think currently the most similar code pattern in stream that enjoys a good performance is:

.mapMulti((x, sink) -> {
    if (x instanceof MyClass myClass) {
        sink.accept(myClass);
    }
})

>From the language point of view, such pattern-match-and-map-0/1 operations may be common.
That said, can we provide a language feature in the future to convert a pattern declaration to BiConsumer>? I believe that is a better way to address the question you have raised here.

Regards,
Chen Liang
________________________________
From: core-libs-dev  on behalf of Nir Lisker 
Sent: Saturday, April 26, 2025 1:55 PM
To: core-libs-dev at openjdk.org 
Subject: Casting gatherer

Hi,

instanceof has been refitted to include an auto-cast ("pattern matching on instanceof"). Unfortunately, doing this as an intermediate operation on a stream requires first to filter via instanceof and then map via a cast. This is because

    x instanceof MyClass myClass

returns a boolean, not myClass.

I've asked for an easier way of doing it long ago directly on Stream and was declined, but now with Gatherers I'm bringing this up again. I think it would be reasonable to put such an operation in the Gatherers class. I imagine that many Gatherer libraries, or utility classes, will include it since it's a common operation, and having it in the JDK means that it'll be done the best way possible (you can optimize where others can't, if applicable here).

-- Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From liach at openjdk.org  Sat Apr 26 19:21:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 26 Apr 2025 19:21:46 GMT
Subject: RFR: 4837946: Faster multiplication and exponentiation of large
 integers [v35]
In-Reply-To: <2Tg_EausewiyR5mEYtVgxoYKHwdc7PLKrf1QzxFzN4Q=.71d5ebb4-acee-42fb-94bb-d0754bddf951@github.com>
References: 
 <2Tg_EausewiyR5mEYtVgxoYKHwdc7PLKrf1QzxFzN4Q=.71d5ebb4-acee-42fb-94bb-d0754bddf951@github.com>
Message-ID: <5xCz-hyBv7dyaOfOKLb8eUOQYHU0Ry-Tl8TNnJAwqQM=.50bf5f40-bbe7-4011-9b57-1d432f3d5195@github.com>

On Sat, 26 Apr 2025 19:11:01 GMT, fabioromano1  wrote:

>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Put power's computation in a stand-alone method

src/java.base/share/classes/java/math/BigInteger.java line 2642:

> 2640:         // Use slightly different algorithms for small and large operands.
> 2641:         // See if the result will safely fit into a long. (Largest 2^63-1)
> 2642:         if (base.mag.length == 1 && scaleFactor <= 62) {

It seems your new `unsignedIntPow` already covers `base.mag.length == 1` case - your `unsignedLongPow` and `unsignedIntPow` are otherwise identical. Can we just remove this long shortcut and `unsignedLongPow` and use the newly established `unsignedIntPow`? That can also remove lots of redundant code and significantly reduce maintenance cost. (Unless BigInteger.multiply(long) is much cheaper than BigInteger.multiply(BigInteger))

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2061552026

From duke at openjdk.org  Sat Apr 26 19:26:46 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 26 Apr 2025 19:26:46 GMT
Subject: RFR: 4837946: Faster multiplication and exponentiation of large
 integers [v35]
In-Reply-To: <5xCz-hyBv7dyaOfOKLb8eUOQYHU0Ry-Tl8TNnJAwqQM=.50bf5f40-bbe7-4011-9b57-1d432f3d5195@github.com>
References: 
 <2Tg_EausewiyR5mEYtVgxoYKHwdc7PLKrf1QzxFzN4Q=.71d5ebb4-acee-42fb-94bb-d0754bddf951@github.com>
 <5xCz-hyBv7dyaOfOKLb8eUOQYHU0Ry-Tl8TNnJAwqQM=.50bf5f40-bbe7-4011-9b57-1d432f3d5195@github.com>
Message-ID: 

On Sat, 26 Apr 2025 19:16:14 GMT, Chen Liang  wrote:

> It seems your new `unsignedIntPow` already covers `base.mag.length == 1` case - your `unsignedLongPow` and `unsignedIntPow` are otherwise identical. Can we just remove this long shortcut and `unsignedLongPow` and use the newly established `unsignedIntPow`? That can also remove lots of redundant code and significantly reduce maintenance cost. (Unless BigInteger.multiply(long) is much cheaper than BigInteger.multiply(BigInteger))

Generally, use privitive integers arithmentic is faster than using BigInteger arithmentic. Anyway, `nthRoot()` depends on `unsignedLongPow()`, so it cannot be avoided without losing performance in nth root computing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2061554538

From liach at openjdk.org  Sat Apr 26 19:32:31 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 26 Apr 2025 19:32:31 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v7]
In-Reply-To: 
References: 
Message-ID: 

> Some AccessFlag parsing methods throw IAE because a flag mask is not valid in a location. However, there is no easy way to check what flag mask bits or what flags are valid for a location. We need such APIs to check, specific to each class file format version.
> 
> Also in the investigation, it's noted that `ACC_SYNTHETIC` is incorrectly represented - it is available since release 5.0 instead of release 7. This bug is fixed together for implementation simplicity.
> 
> The new methods are all in `AccessFlag.Location`:
> - `Set flags()`
> - `int flagsMask()`
> - `Set flags(ClassFileFormatVersion)`
> - `int flagsMask(ClassFileFormatVersion)`
> 
> Also there is some simplification to `AccessFlag` itself to remove the anonymous classes, which should be more startup-friendly.
> 
> Testing: Tier 1-3

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-location-accessors
 - Doc updates, also put access flag set to collections test
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-location-accessors
 - Preview notes
 - Further enhance the impl of access flags, make cffv aware to flags easier
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-location-accessors
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-location-accessors
 - More links
 - ClassLoading order, Typos in NPE test
 - 8347471: Provide valid flags and mask in AccessFlag.Location

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23095/files
  - new: https://git.openjdk.org/jdk/pull/23095/files/1019812f..b89dc13e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23095&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23095&range=05-06

  Stats: 3682 lines in 112 files changed: 2426 ins; 844 del; 412 mod
  Patch: https://git.openjdk.org/jdk/pull/23095.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23095/head:pull/23095

PR: https://git.openjdk.org/jdk/pull/23095

From duke at openjdk.org  Sat Apr 26 19:35:46 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 26 Apr 2025 19:35:46 GMT
Subject: RFR: 4837946: Faster multiplication and exponentiation of large
 integers [v35]
In-Reply-To: 
References: 
 <2Tg_EausewiyR5mEYtVgxoYKHwdc7PLKrf1QzxFzN4Q=.71d5ebb4-acee-42fb-94bb-d0754bddf951@github.com>
 <5xCz-hyBv7dyaOfOKLb8eUOQYHU0Ry-Tl8TNnJAwqQM=.50bf5f40-bbe7-4011-9b57-1d432f3d5195@github.com>
 
Message-ID: 

On Sat, 26 Apr 2025 19:24:21 GMT, fabioromano1  wrote:

> It seems your new `unsignedIntPow` already covers `base.mag.length == 1` case - your `unsignedLongPow` and `unsignedIntPow` are otherwise identical. Can we just remove this long shortcut and `unsignedLongPow` and use the newly established `unsignedIntPow`? That can also remove lots of redundant code and significantly reduce maintenance cost. (Unless BigInteger.multiply(long) is much cheaper than BigInteger.multiply(BigInteger))

An alternative solution is to simply throw away `unsignedIntPow()` and use always BigInteger arithmetic when the result could exceed a the `long` bits size.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2061559369

From liach at openjdk.org  Sat Apr 26 19:44:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 26 Apr 2025 19:44:02 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v8]
In-Reply-To: 
References: 
Message-ID: 

> Some AccessFlag parsing methods throw IAE because a flag mask is not valid in a location. However, there is no easy way to check what flag mask bits or what flags are valid for a location. We need such APIs to check, specific to each class file format version.
> 
> Also in the investigation, it's noted that `ACC_SYNTHETIC` is incorrectly represented - it is available since release 5.0 instead of release 7. This bug is fixed together for implementation simplicity.
> 
> The new methods are all in `AccessFlag.Location`:
> - `Set flags()`
> - `int flagsMask()`
> - `Set flags(ClassFileFormatVersion)`
> - `int flagsMask(ClassFileFormatVersion)`
> 
> Also there is some simplification to `AccessFlag` itself to remove the anonymous classes, which should be more startup-friendly.
> 
> Testing: Tier 1-3

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Fix iterator missing NSEE

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23095/files
  - new: https://git.openjdk.org/jdk/pull/23095/files/b89dc13e..f091b912

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23095&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23095&range=06-07

  Stats: 6 lines in 2 files changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23095.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23095/head:pull/23095

PR: https://git.openjdk.org/jdk/pull/23095

From asemenyuk at openjdk.org  Sat Apr 26 19:53:57 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 26 Apr 2025 19:53:57 GMT
Subject: RFR: 8319457: Update jpackage to support WiX v4 and v5 on Windows
In-Reply-To: <9yH-cW3pckTJWtokFbmYu6NOtZ7lTfLHJSUmEFMQows=.52fe3bca-be29-4888-9a50-617cdec5c8cb@github.com>
References: 
 
 
 
 
 
 
 <9yH-cW3pckTJWtokFbmYu6NOtZ7lTfLHJSUmEFMQows=.52fe3bca-be29-4888-9a50-617cdec5c8cb@github.com>
Message-ID: 

On Sat, 26 Apr 2025 13:17:16 GMT, Oliver Kopp  wrote:

> I would expect that all files are available before the "Post-image script" are available

Definitely. Thank you for reporting the issue. Filed https://bugs.openjdk.org/browse/JDK-8355651 to track fixing the issue

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19318#issuecomment-2832570603

From liach at openjdk.org  Sat Apr 26 20:10:19 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 26 Apr 2025 20:10:19 GMT
Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to
 class file version [v2]
In-Reply-To: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
Message-ID: 

> Take the class file version to reject flags not yet defined, redefined, or obsoleted. The non-cffv version can return the preview flags when the current runtime is in preview.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Further furnish docs
 - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
 - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-cffv-parse
 - Redundant method
 - 8297271: AccessFlag.maskToAccessFlags should be specific to class file version

-------------

Changes: https://git.openjdk.org/jdk/pull/24760/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24760&range=01
  Stats: 161 lines in 9 files changed: 94 ins; 33 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/24760.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24760/head:pull/24760

PR: https://git.openjdk.org/jdk/pull/24760

From davidalayachew at gmail.com  Sat Apr 26 20:22:21 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Sat, 26 Apr 2025 16:22:21 -0400
Subject: Casting gatherer
In-Reply-To: 
References: 
 
Message-ID: 

Didn't Brian or one of the Amber folks say that we might (some time in the
near future) get a .match() method on streams, which can take in a pattern?
It's the pattern version of .map().

On Sat, Apr 26, 2025 at 3:13?PM Chen Liang  wrote:

> Hi Nir, I think currently the most similar code pattern in stream that
> enjoys a good performance is:
>
> .mapMulti((x, sink) -> {
>     if (x instanceof MyClass myClass) {
>         sink.accept(myClass);
>     }
> })
>
> From the language point of view, such pattern-match-and-map-0/1 operations
> may be common.
> That said, can we provide a language feature in the future to convert a
> pattern declaration to BiConsumer>? I believe that is
> a better way to address the question you have raised here.
>
> Regards,
> Chen Liang
> ------------------------------
> *From:* core-libs-dev  on behalf of Nir
> Lisker 
> *Sent:* Saturday, April 26, 2025 1:55 PM
> *To:* core-libs-dev at openjdk.org 
> *Subject:* Casting gatherer
>
> Hi,
>
> instanceof has been refitted to include an auto-cast ("pattern matching on
> instanceof"). Unfortunately, doing this as an intermediate operation on a
> stream requires first to filter via instanceof and then map via a cast.
> This is because
>
>     x instanceof MyClass myClass
>
> returns a boolean, not myClass.
>
> I've asked for an easier way of doing it long ago directly on Stream and
> was declined, but now with Gatherers I'm bringing this up again. I think it
> would be reasonable to put such an operation in the Gatherers class. I
> imagine that many Gatherer libraries, or utility classes, will include it
> since it's a common operation, and having it in the JDK means that it'll be
> done the best way possible (you can optimize where others can't, if
> applicable here).
>
> -- Nir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From chen.l.liang at oracle.com  Sat Apr 26 20:42:16 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Sat, 26 Apr 2025 20:42:16 +0000
Subject: [External] : Re: Casting gatherer
In-Reply-To: 
References: 
 
 
Message-ID: 

Hmm, thanks for the reminder; unfortunately I did not pay close attention to the progress of amber and don't know about the details. I might ask Amber folks in private and share if we have a roadmap for this feature.
________________________________
From: David Alayachew 
Sent: Saturday, April 26, 2025 3:22 PM
To: Chen Liang 
Cc: Nir Lisker ; core-libs-dev at openjdk.org ; amber-dev 
Subject: [External] : Re: Casting gatherer

Didn't Brian or one of the Amber folks say that we might (some time in the near future) get a .match() method on streams, which can take in a pattern? It's the pattern version of .map().

On Sat, Apr 26, 2025 at 3:13?PM Chen Liang > wrote:
Hi Nir, I think currently the most similar code pattern in stream that enjoys a good performance is:

.mapMulti((x, sink) -> {
    if (x instanceof MyClass myClass) {
        sink.accept(myClass);
    }
})

From the language point of view, such pattern-match-and-map-0/1 operations may be common.
That said, can we provide a language feature in the future to convert a pattern declaration to BiConsumer>? I believe that is a better way to address the question you have raised here.

Regards,
Chen Liang
________________________________
From: core-libs-dev > on behalf of Nir Lisker >
Sent: Saturday, April 26, 2025 1:55 PM
To: core-libs-dev at openjdk.org >
Subject: Casting gatherer

Hi,

instanceof has been refitted to include an auto-cast ("pattern matching on instanceof"). Unfortunately, doing this as an intermediate operation on a stream requires first to filter via instanceof and then map via a cast. This is because

    x instanceof MyClass myClass

returns a boolean, not myClass.

I've asked for an easier way of doing it long ago directly on Stream and was declined, but now with Gatherers I'm bringing this up again. I think it would be reasonable to put such an operation in the Gatherers class. I imagine that many Gatherer libraries, or utility classes, will include it since it's a common operation, and having it in the JDK means that it'll be done the best way possible (you can optimize where others can't, if applicable here).

-- Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Sat Apr 26 20:45:25 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 26 Apr 2025 20:45:25 GMT
Subject: RFR: 4837946: Faster multiplication and exponentiation of large
 integers [v36]
In-Reply-To: 
References: 
Message-ID: <6GkLPLSKYsg52qVEL7QJwzXToi_tkhCW_7DSycJNvqA=.8fbc78f3-7858-491d-bfaa-62fc7032800a@github.com>

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Optimized BigInteger.pow(int) to support unsigned long bases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/10e122e0..b94ca7e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=34-35

  Stats: 35 lines in 1 file changed: 12 ins; 8 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From duke at openjdk.org  Sat Apr 26 21:21:25 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 26 Apr 2025 21:21:25 GMT
Subject: RFR: 4837946: Faster multiplication and exponentiation of large
 integers [v37]
In-Reply-To: 
References: 
Message-ID: 

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Use BigInteger(long, int) constructor

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/b94ca7e0..139735d9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=35-36

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From duke at openjdk.org  Sat Apr 26 21:48:25 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 26 Apr 2025 21:48:25 GMT
Subject: RFR: 4837946: Faster multiplication and exponentiation of large
 integers [v38]
In-Reply-To: 
References: 
Message-ID: 

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Throw away unsignedIntPow(int, int)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/139735d9..fcd5d550

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=37
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=36-37

  Stats: 95 lines in 1 file changed: 0 ins; 86 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From swen at openjdk.org  Sat Apr 26 22:36:44 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 26 Apr 2025 22:36:44 GMT
Subject: RFR: 8355442: Reference field lambda forms with type casts are not
 generated
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Apr 2025 20:30:15 GMT, Chen Liang  wrote:

> Currently, we are not generating all possible field lambda forms.
> 
> Field lambda forms have these dimensions:
> - get/set
> - instance/static/static+class init barrier
> - plain/volatile
> - 8 primitive types, no-cast object, object with cast
> 
> Bringing to a total of 2 ? 3 ? 2 ? 10 = 120 lambda forms.
> 
> Previously, the ones with init barrier or object with cast types were not generated due to spamming the Kind enum. In retrospect, I believe skipping the object with cast form is a poor choice - tons of Java fields are using non-interface types. Also seems the volatile accessors were omitted in InvokerBytecodeGenerator, which made their pregen useless.
> 
> I have utilized erased method types to distinguish forms - get/set, 5 basic types, and instance/static can be distinguished by the types, so the Kind enums now only represent init, volatile, and non-basic types (byte, char, short, boolean, casts), bringing the total constants to 24 down from 40 previously.
> 
> In the long run, we should investigate update `Kind` to allow flexible representations - an enum is too restrictive especially with the erased types.

src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java line 741:

> 739:             case VOID -> throw new InternalError();
> 740:         };
> 741:         StringBuilder sb = new StringBuilder(3 + name.length() + (isVolatile ? 8 : 0))

var sb = new StringBuilder(3 + name.length() + (isVolatile ? 8 : 0))

--------
The type of StringBulder sb here is clear, can we use var?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24887#discussion_r2061664197

From swen at openjdk.org  Sat Apr 26 22:42:08 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 26 Apr 2025 22:42:08 GMT
Subject: RFR: 8355636: Reuse StringBuilder in printStackTrace [v7]
In-Reply-To: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
References: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
Message-ID: 

> In the Throwable::printStackTrace method, StringBuilder is created multiple times to build String. By sharing StringBuilder to build String, object allocation and copying are reduced.
> 
> In the scenario without suppressed and ourCause, unused IdentityHashMap is not created.
> 
> Through these optimizations, the performance of `new Exception().printStackTrace()` can be improved by about 10%.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/Throwable.java
  
  Co-authored-by: Hendrik Schick <30866028+ky0n at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24864/files
  - new: https://git.openjdk.org/jdk/pull/24864/files/6160f403..6bbe90f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24864&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24864&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24864.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24864/head:pull/24864

PR: https://git.openjdk.org/jdk/pull/24864

From liach at openjdk.org  Sat Apr 26 23:47:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 26 Apr 2025 23:47:01 GMT
Subject: RFR: 8355442: Reference field lambda forms with type casts are not
 generated [v2]
In-Reply-To: 
References: 
Message-ID: 

> Currently, we are not generating all possible field lambda forms.
> 
> Field lambda forms have these dimensions:
> - get/set
> - instance/static/static+class init barrier
> - plain/volatile
> - 8 primitive types, no-cast object, object with cast
> 
> Bringing to a total of 2 ? 3 ? 2 ? 10 = 120 lambda forms.
> 
> Previously, the ones with init barrier or object with cast types were not generated due to spamming the Kind enum. In retrospect, I believe skipping the object with cast form is a poor choice - tons of Java fields are using non-interface types. Also seems the volatile accessors were omitted in InvokerBytecodeGenerator, which made their pregen useless.
> 
> I have utilized erased method types to distinguish forms - get/set, 5 basic types, and instance/static can be distinguished by the types, so the Kind enums now only represent init, volatile, and non-basic types (byte, char, short, boolean, casts), bringing the total constants to 24 down from 40 previously.
> 
> In the long run, we should investigate update `Kind` to allow flexible representations - an enum is too restrictive especially with the erased types.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  use var

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24887/files
  - new: https://git.openjdk.org/jdk/pull/24887/files/f6503142..f45160e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24887&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24887&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24887.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24887/head:pull/24887

PR: https://git.openjdk.org/jdk/pull/24887

From liach at openjdk.org  Sun Apr 27 02:09:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 27 Apr 2025 02:09:40 GMT
Subject: RFR: 8341275: Explicit counter support for Code attribute building
Message-ID: 

Internal explicit counter support for Code max_stack and max_locals has been already added in #24807. Since that example works well, we may consider opening this functionality up to general users under strict restrictions.

This is an advanced API; thus, I chose a more complex name `withExplicitStackAndLocals` that discourages accidental use, and indicates the exact order of stack and locals arguments. For integrity, the argument checks are unconditional. And this is also barred behind `DROP_STACK_MAPS` advanced option.

I have enhanced the tests with a `CodeBuilderType` utility to test all types of code builders; it is already effective at increasing coverage in some of our existing tests that only cover DirectCodeBuilder, and simplify other tests. It is particularly helpful for my new `BuilderExplicitMaxsTest`.

-------------

Commit messages:
 - 8341275: Explicit counter support for Code attribute building

Changes: https://git.openjdk.org/jdk/pull/24903/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24903&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341275
  Stats: 314 lines in 10 files changed: 262 ins; 19 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/24903.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24903/head:pull/24903

PR: https://git.openjdk.org/jdk/pull/24903

From liach at openjdk.org  Sun Apr 27 02:10:33 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 27 Apr 2025 02:10:33 GMT
Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to
 class file version [v3]
In-Reply-To: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
Message-ID: 

> Take the class file version to reject flags not yet defined, redefined, or obsoleted. The non-cffv version can return the preview flags when the current runtime is in preview.

Chen Liang has updated the pull request incrementally with two additional commits since the last revision:

 - Missing since
 - Fix javap causing strictfp tests to fail

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24760/files
  - new: https://git.openjdk.org/jdk/pull/24760/files/e1530d7d..3db05342

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24760&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24760&range=01-02

  Stats: 72 lines in 7 files changed: 17 ins; 19 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/24760.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24760/head:pull/24760

PR: https://git.openjdk.org/jdk/pull/24760

From jrose at openjdk.org  Sun Apr 27 02:30:53 2025
From: jrose at openjdk.org (John R Rose)
Date: Sun, 27 Apr 2025 02:30:53 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 21 Mar 2025 19:44:48 GMT, Chen Liang  wrote:

>> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
>> 
>> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
>> 
>> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
>> 
>> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   docs

I made some changes. See what you think...
[ClassValue.java.txt](https://github.com/user-attachments/files/19926562/ClassValue.java.txt)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24043#issuecomment-2832906687

From asemenyuk at openjdk.org  Sun Apr 27 02:59:15 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sun, 27 Apr 2025 02:59:15 GMT
Subject: RFR: 8355651: Premature execution of post-image hook
Message-ID: <5RuvuTl0kW-MbAAb0sJb1zkBnWUAnNTHKp2r8wQwiz8=.34a6dd59-aa49-4f51-b128-222e4116e922@github.com>

Reorder the calling of a custom "post-image" script in MSI packaging.

Add a relevant test.

-------------

Commit messages:
 - Test the current directory of the post-image script is the root directory for app image.
 - 8355651: Premature execution of post-image hook

Changes: https://git.openjdk.org/jdk/pull/24899/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24899&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355651
  Stats: 105 lines in 2 files changed: 61 ins; 21 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/24899.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24899/head:pull/24899

PR: https://git.openjdk.org/jdk/pull/24899

From asemenyuk at openjdk.org  Sun Apr 27 02:59:15 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sun, 27 Apr 2025 02:59:15 GMT
Subject: RFR: 8355651: Premature execution of post-image hook
In-Reply-To: <5RuvuTl0kW-MbAAb0sJb1zkBnWUAnNTHKp2r8wQwiz8=.34a6dd59-aa49-4f51-b128-222e4116e922@github.com>
References: <5RuvuTl0kW-MbAAb0sJb1zkBnWUAnNTHKp2r8wQwiz8=.34a6dd59-aa49-4f51-b128-222e4116e922@github.com>
Message-ID: 

On Sat, 26 Apr 2025 21:31:35 GMT, Alexey Semenyuk  wrote:

> Reorder the calling of a custom "post-image" script in MSI packaging.
> 
> Add a relevant test.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24899#issuecomment-2832921058

From liach at openjdk.org  Sun Apr 27 03:29:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 27 Apr 2025 03:29:54 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v5]
In-Reply-To: 
References: 
 
Message-ID: <-hMPGS2A32I2hVOdrRJ5OsN_phHrHnx4QJd_BvYgE5I=.2ceff351-5d8d-454d-b704-a547729e71c4@github.com>

On Fri, 21 Mar 2025 19:44:48 GMT, Chen Liang  wrote:

>> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
>> 
>> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
>> 
>> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
>> 
>> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   docs

Ah, I see. Here is my understanding:
1. Making StackOverflowError more explicit
2. Best attempt to fetch a bound value before failing

Looks sensible; the finishEntry fetch of a bound value is indeed an improvement.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24043#issuecomment-2832935740

From swen at openjdk.org  Sun Apr 27 03:31:49 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 27 Apr 2025 03:31:49 GMT
Subject: RFR: 8341275: Explicit counter support for Code attribute building
In-Reply-To: 
References: 
Message-ID: 

On Sun, 27 Apr 2025 02:04:30 GMT, Chen Liang  wrote:

> Internal explicit counter support for Code max_stack and max_locals has been already added in #24807. Since that example works well, we may consider opening this functionality up to general users under strict restrictions.
> 
> This is an advanced API; thus, I chose a more complex name `withExplicitStackAndLocals` that discourages accidental use, and indicates the exact order of stack and locals arguments. For integrity, the argument checks are unconditional. And this is also barred behind `DROP_STACK_MAPS` advanced option.
> 
> I have enhanced the tests with a `CodeBuilderType` utility to test all types of code builders; it is already effective at increasing coverage in some of our existing tests that only cover DirectCodeBuilder, and simplify other tests. It is particularly helpful for my new `BuilderExplicitMaxsTest`.

test/jdk/jdk/classfile/BuilderExplicitMaxsTest.java line 67:

> 65:     void testValidArgs(ClassFile.StackMapsOption stackMapsOption, CodeBuilderType builderType) {
> 66:         var cc = ClassFile.of(stackMapsOption);
> 67:         var bytes = cc.build(ClassDesc.of("Foo"), builderType.asClassHandler("foo", MTD_void, 0, cob -> cob

var bytes = cc.build(
                        ClassDesc.of("Foo"), 
                        builderType.asClassHandler(
                                "foo", 
                                MTD_void, 
                                0, 
                                cob -> cob.return_()
                                          .withExplicitStackAndLocals(2, 3)));

This might be more readable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24903#discussion_r2061984210

From liach at openjdk.org  Sun Apr 27 03:38:35 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 27 Apr 2025 03:38:35 GMT
Subject: RFR: 8341275: Explicit counter support for Code attribute building
 [v2]
In-Reply-To: 
References: 
Message-ID: <0QEX0NA3qOGsRadwDcp42BhyOeZl09677eskI00x7Lo=.bd667709-7c30-4489-8013-411326e63813@github.com>

> Internal explicit counter support for Code max_stack and max_locals has been already added in #24807. Since that example works well, we may consider opening this functionality up to general users under strict restrictions.
> 
> This is an advanced API; thus, I chose a more complex name `withExplicitStackAndLocals` that discourages accidental use, and indicates the exact order of stack and locals arguments. For integrity, the argument checks are unconditional. And this is also barred behind `DROP_STACK_MAPS` advanced option.
> 
> I have enhanced the tests with a `CodeBuilderType` utility to test all types of code builders; it is already effective at increasing coverage in some of our existing tests that only cover DirectCodeBuilder, and simplify other tests. It is particularly helpful for my new `BuilderExplicitMaxsTest`.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Adjust indents

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24903/files
  - new: https://git.openjdk.org/jdk/pull/24903/files/e60e3e07..989a494a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24903&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24903&range=00-01

  Stats: 29 lines in 2 files changed: 7 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/24903.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24903/head:pull/24903

PR: https://git.openjdk.org/jdk/pull/24903

From liach at openjdk.org  Sun Apr 27 03:38:35 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 27 Apr 2025 03:38:35 GMT
Subject: RFR: 8341275: Explicit counter support for Code attribute building
In-Reply-To: 
References: 
Message-ID: <_ubU8drqAyYW4q4CpZEIqyNjQkPit6wn9Wm6-S07Q_k=.982fa927-d11b-436e-91f3-d6cc594f0d55@github.com>

On Sun, 27 Apr 2025 02:04:30 GMT, Chen Liang  wrote:

> Internal explicit counter support for Code max_stack and max_locals has been already added in #24807. Since that example works well, we may consider opening this functionality up to general users under strict restrictions.
> 
> This is an advanced API; thus, I chose a more complex name `withExplicitStackAndLocals` that discourages accidental use, and indicates the exact order of stack and locals arguments. For integrity, the argument checks are unconditional. And this is also barred behind `DROP_STACK_MAPS` advanced option.
> 
> I have enhanced the tests with a `CodeBuilderType` utility to test all types of code builders; it is already effective at increasing coverage in some of our existing tests that only cover DirectCodeBuilder, and simplify other tests. It is particularly helpful for my new `BuilderExplicitMaxsTest`.

Testing: tier 1-3

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24903#issuecomment-2832940873

From liach at openjdk.org  Sun Apr 27 04:29:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 27 Apr 2025 04:29:47 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v5]
In-Reply-To: 
References: 
 
Message-ID: <6eZiY-aoL1r2cWYze7ieXsCkWQQtfIzq6DJH7K8y27E=.3a88f7be-a5fd-4b50-9d39-4c120d5eef28@github.com>

On Fri, 21 Mar 2025 19:44:48 GMT, Chen Liang  wrote:

>> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
>> 
>> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
>> 
>> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
>> 
>> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   docs

Turns out we do need to allow a few levels of recursion - see https://github.com/openjdk/jdk/blob/942402bab8a632f9e8a9b0c56201e2ab0571e6e8/test/jdk/java/io/Serializable/recursiveClassDescLookup/Test.java where a computeValue triggers class initialization, which itself triggers another computeValue that finishes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24043#issuecomment-2833091944

From liach at openjdk.org  Sun Apr 27 04:50:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 27 Apr 2025 04:50:37 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v6]
In-Reply-To: 
References: 
Message-ID: 

> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
> 
> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
> 
> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
> 
> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Cannot test for recursion eagerly - add test case
 - More spec, eager exception, finish with existing, thanks John
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
 - docs
 - Remove the throwing behavior due to shallow reentrancy
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
 - Add more tests to avoid critical errors like the last one
 - Major typo
 - Use identity of thread, some optimizations for single thread case
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
 - ... and 2 more: https://git.openjdk.org/jdk/compare/077433dc...edd19537

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24043/files
  - new: https://git.openjdk.org/jdk/pull/24043/files/ab86b41f..edd19537

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=04-05

  Stats: 351437 lines in 4164 files changed: 101850 ins; 235918 del; 13669 mod
  Patch: https://git.openjdk.org/jdk/pull/24043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24043/head:pull/24043

PR: https://git.openjdk.org/jdk/pull/24043

From jrose at openjdk.org  Sun Apr 27 05:31:50 2025
From: jrose at openjdk.org (John R Rose)
Date: Sun, 27 Apr 2025 05:31:50 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 27 Apr 2025 04:50:37 GMT, Chen Liang  wrote:

>> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
>> 
>> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
>> 
>> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
>> 
>> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Cannot test for recursion eagerly - add test case
>  - More spec, eager exception, finish with existing, thanks John
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - docs
>  - Remove the throwing behavior due to shallow reentrancy
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - Add more tests to avoid critical errors like the last one
>  - Major typo
>  - Use identity of thread, some optimizations for single thread case
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/b0b85ba9...edd19537

One thing I didn't note in the javadoc, but which might be significant, is that `computeValue` calls can be restarted for unpredictable reasons.  I gave some of them in the javadoc, but not all.  I did not document the possibility of crosstalk between  pairs.  Another pair  might do a remove and update the internal CV version.  The purpose of htis is to flush the CV cache.  But it also creates an interference with ongoing computation of `computeValue` for the original  pair.  Maybe we should treat such crosstalk as a bug.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24043#issuecomment-2833168973

From jrose at openjdk.org  Sun Apr 27 05:28:49 2025
From: jrose at openjdk.org (John R Rose)
Date: Sun, 27 Apr 2025 05:28:49 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v6]
In-Reply-To: 
References: 
 
Message-ID: <-5FuE3YT8LooVno9rIEE7wK3zoejetfdNwakEZJoLKg=.f5a45ef2-d492-42d8-bad6-53ea7c62f3d3@github.com>

On Sun, 27 Apr 2025 04:50:37 GMT, Chen Liang  wrote:

>> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
>> 
>> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
>> 
>> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
>> 
>> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Cannot test for recursion eagerly - add test case
>  - More spec, eager exception, finish with existing, thanks John
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - docs
>  - Remove the throwing behavior due to shallow reentrancy
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - Add more tests to avoid critical errors like the last one
>  - Major typo
>  - Use identity of thread, some optimizations for single thread case
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/01c000e3...edd19537

Good catch.  Yes, there are legitimate uses of bounded recursive calls to get.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24043#issuecomment-2833167016

From liach at openjdk.org  Sun Apr 27 05:56:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 27 Apr 2025 05:56:49 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 27 Apr 2025 04:50:37 GMT, Chen Liang  wrote:

>> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
>> 
>> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
>> 
>> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
>> 
>> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Cannot test for recursion eagerly - add test case
>  - More spec, eager exception, finish with existing, thanks John
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - docs
>  - Remove the throwing behavior due to shallow reentrancy
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - Add more tests to avoid critical errors like the last one
>  - Major typo
>  - Use identity of thread, some optimizations for single thread case
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/e78f8c09...edd19537

Hmm, this interference probably comes from `startEntry` checking `e.isPromise()` and `e.version() != v`. The version check should be redundant - it is only relevant when you finish (you finished an outdated computation). Whatever is in the root map is valid regardless of its version.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24043#issuecomment-2833184065

From duke at openjdk.org  Sun Apr 27 09:15:48 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sun, 27 Apr 2025 09:15:48 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Apr 2025 12:39:05 GMT, Jan Lahoda  wrote:

>> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
>> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
>> - `java. ... .IO` is no longer automatically imported in any compilation unit
>> - the feature is finalized (i.e. no longer requires `--enable-preview`)
>
> Jan Lahoda has updated the pull request incrementally with seven additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/finalize-concise-source-files' into finalize-concise-source-files
>  - Reverting test commit.
>    
>    This reverts commit 7047cf007cc7de937aa21e96125083ee92932692.
>  - Fixing tests.
>  - Updating copyright year.
>  - Adding bug number to tests.
>  - Fixing IO tests path
>  - Scratch

src/java.base/share/classes/java/lang/IO.java line 192:

> 190:             String enc = System.getProperty("stdin.encoding", "");
> 191:             Charset cs = Charset.forName(enc, StandardCharsets.UTF_8);
> 192:             br = new BufferedReader(new InputStreamReader(System.in, cs));

I suspect we need to fall back to `stdout.encoding` first before UTF-8 especially for Windows if Java does not set it automatically when launched.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2062571907

From jpai at openjdk.org  Sun Apr 27 09:40:49 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 27 Apr 2025 09:40:49 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v8]
In-Reply-To: <1s3MwTXb7v_7WWORxAL4WXOlbMOnpCkt8kbjc613-UM=.a81c62cc-4cc5-4714-8d3b-a63f0b9e092d@github.com>
References: 
 <1s3MwTXb7v_7WWORxAL4WXOlbMOnpCkt8kbjc613-UM=.a81c62cc-4cc5-4714-8d3b-a63f0b9e092d@github.com>
Message-ID: <_JPACPp1_26dHzjeJL3L2WZ8lkB8zQYmjCQxhgrkicQ=.38264b48-e5ab-4ea5-bdfb-c3fd26203bd4@github.com>

On Sat, 26 Apr 2025 17:07:33 GMT, Markus KARG  wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.'

Thank you Markus for adding the new tests, I'm happy to see the new default methods getting the test coverage.

The `CharSequence` test looks good to me. So does the `CharBuffer` one, but I'll let Alan take a look at that one given similar existing tests in the nio/Buffer area.

I only have some javadoc related minor nits to the text, but I'll wait for the discussion on CSR to settle before deciding if those are still applicable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2833354644

From jpai at openjdk.org  Sun Apr 27 09:41:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 27 Apr 2025 09:41:55 GMT
Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed
 with "RuntimeException: MyObject is not found in test output" [v5]
In-Reply-To: <6FbcHJgoBqT54MMlshTquDhF3VwEPWlR2HXcx1hFt4o=.8f06a700-2720-467a-9d2c-7ed4af277658@github.com>
References: 
 <6FbcHJgoBqT54MMlshTquDhF3VwEPWlR2HXcx1hFt4o=.8f06a700-2720-467a-9d2c-7ed4af277658@github.com>
Message-ID: 

On Fri, 25 Apr 2025 21:30:10 GMT, Brent Christian  wrote:

>> I propose some cleanups to `FinalizerHistogramTest.java` to hopefully clear up the intermittent failures:
>> 
>> * run with `othervm`: this test blocks the (global) finalizer thread, and also requires the (global) finalizer thread to enter the test's `finalize()` method
>> * The test uses `volatile` ints, but sets them based on their current value, which is not reliable; convert to `AtomicInteger`
>> * use `PhantomReference`s to ensure that at least two `MyObject`s have become unreachable. If one is stuck in `finalize()`, at least one is still waiting to be finalized and should show up in the histogram.
>
> Brent Christian 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 'master' into 8298783
>  - convert to WeakRefs, use a RefQ, print ForceGC results
>  - 'return' not needed in lambda
>  - rename counter variables to use 'Count'
>  - test reliability improvements

Still looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24143#pullrequestreview-2797581405

From duke at openjdk.org  Sun Apr 27 10:12:45 2025
From: duke at openjdk.org (erifan)
Date: Sun, 27 Apr 2025 10:12:45 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v2]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Fri, 25 Apr 2025 09:48:59 GMT, Jatin Bhateja  wrote:

>> Since this is a platform independent optimization, I tend to use this `@requires` because it's simpler.  If we use `applyIfCPUFeatureOr`, we need to add the same restriction before each test. In addition, if a new architecture supports the vector node, this test may not cover it. What do you think?
>
> I don't see XorVMask implemented on all non-x86 target, like PPC etc..

This is not specifically required on x86, but because this test fails on x86 when `-XX:UseAVX=0` is specified. When `-XX:UseAVX=0` is specified, the sub-graph is like this:
`(XorV (VectorMaskCmp (LoadVector ...)) (Replicate -1))`
It is not an optimization pattern supported by this patch because we don't know what's the comparison op.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2062583790

From kbarrett at openjdk.org  Sun Apr 27 10:13:49 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 27 Apr 2025 10:13:49 GMT
Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed
 with "RuntimeException: MyObject is not found in test output" [v5]
In-Reply-To: <6FbcHJgoBqT54MMlshTquDhF3VwEPWlR2HXcx1hFt4o=.8f06a700-2720-467a-9d2c-7ed4af277658@github.com>
References: 
 <6FbcHJgoBqT54MMlshTquDhF3VwEPWlR2HXcx1hFt4o=.8f06a700-2720-467a-9d2c-7ed4af277658@github.com>
Message-ID: <-LX-FH4kCIFqS2ihf4AmcRUECCL3tP3py901MOtHmmM=.691894ac-da8c-44ef-84f3-f73d36121b4e@github.com>

On Fri, 25 Apr 2025 21:30:10 GMT, Brent Christian  wrote:

>> I propose some cleanups to `FinalizerHistogramTest.java` to hopefully clear up the intermittent failures:
>> 
>> * run with `othervm`: this test blocks the (global) finalizer thread, and also requires the (global) finalizer thread to enter the test's `finalize()` method
>> * The test uses `volatile` ints, but sets them based on their current value, which is not reliable; convert to `AtomicInteger`
>> * use `PhantomReference`s to ensure that at least two `MyObject`s have become unreachable. If one is stuck in `finalize()`, at least one is still waiting to be finalized and should show up in the histogram.
>
> Brent Christian 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 'master' into 8298783
>  - convert to WeakRefs, use a RefQ, print ForceGC results
>  - 'return' not needed in lambda
>  - rename counter variables to use 'Count'
>  - test reliability improvements

Changes requested by kbarrett (Reviewer).

test/jdk/java/lang/ref/FinalizerHistogramTest.java line 84:

> 82:             System.out.println("ref1Cleared: " + refQForTwo.ref1Cleared);
> 83:             System.out.println("ref2Cleared: " + refQForTwo.ref2Cleared);
> 84:             System.out.println("trappedCount.intValue(): " + trappedCount.intValue());

This could be made completely reliable, and much simpler, by using WhiteBox.

Don't introduce RefQForTwo.  (It doesn't provide reliable information.)

Use WhiteBox::fullGC() to trigger finalization, instead of ForceGC.

Use (new) WhiteBox::waitForReferenceProcessing() to wait until the
FinalReferences have been enqueued (and mostly trapped in the queue).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24143#pullrequestreview-2797589587
PR Review Comment: https://git.openjdk.org/jdk/pull/24143#discussion_r2062584077

From jlahoda at openjdk.org  Sun Apr 27 10:53:49 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Sun, 27 Apr 2025 10:53:49 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sun, 27 Apr 2025 09:12:47 GMT, Tatsunori Uchino  wrote:

>> Jan Lahoda has updated the pull request incrementally with seven additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/finalize-concise-source-files' into finalize-concise-source-files
>>  - Reverting test commit.
>>    
>>    This reverts commit 7047cf007cc7de937aa21e96125083ee92932692.
>>  - Fixing tests.
>>  - Updating copyright year.
>>  - Adding bug number to tests.
>>  - Fixing IO tests path
>>  - Scratch
>
> src/java.base/share/classes/java/lang/IO.java line 192:
> 
>> 190:             String enc = System.getProperty("stdin.encoding", "");
>> 191:             Charset cs = Charset.forName(enc, StandardCharsets.UTF_8);
>> 192:             br = new BufferedReader(new InputStreamReader(System.in, cs));
> 
> I suspect we need to fall back to `stdout.encoding` first before UTF-8 especially for Windows if Java does not set `stdin.encoding` automatically when launched.

I believe that after:
https://github.com/openjdk/jdk/pull/24738
the `stdin.encoding` property is set when the process is connected to a console, which is probably the main case where the encoding can be detected automatically.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2062592200

From duke at openjdk.org  Sun Apr 27 12:28:07 2025
From: duke at openjdk.org (fabioromano1)
Date: Sun, 27 Apr 2025 12:28:07 GMT
Subject: RFR: 8077587: BigInteger Roots [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for BigIntegers using Newton method. This PR is dependent by this [PR](https://github.com/openjdk/jdk/pull/24690).

fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:

 - Correct typo in comment
 - No need to avoid overflow

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/f9bfd22c..427a73e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 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 duke at openjdk.org  Sun Apr 27 14:23:50 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sun, 27 Apr 2025 14:23:50 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Sun, 27 Apr 2025 10:51:33 GMT, Jan Lahoda  wrote:

>> src/java.base/share/classes/java/lang/IO.java line 192:
>> 
>>> 190:             String enc = System.getProperty("stdin.encoding", "");
>>> 191:             Charset cs = Charset.forName(enc, StandardCharsets.UTF_8);
>>> 192:             br = new BufferedReader(new InputStreamReader(System.in, cs));
>> 
>> I suspect we need to fall back to `stdout.encoding` first before UTF-8 especially for Windows if Java does not set `stdin.encoding` automatically when launched.
>
> I believe that after:
> https://github.com/openjdk/jdk/pull/24738
> the `stdin.encoding` property is set when the process is connected to a console, which is probably the main case where the encoding can be detected automatically.

I misunderstood that I have tested `stdin.encoding`.
I cannot confirm that `stdin.encoding` is changed in Windows to proper ones because it has not been included in the latest EA build (20) and I cannot build master for Windows. However, it is changed to `US-ASCII` in Ubuntu when I change `LANG`. I will believe its author until the latest EA build is updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2062641495

From duke at openjdk.org  Sun Apr 27 14:26:50 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sun, 27 Apr 2025 14:26:50 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v5]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Sun, 27 Apr 2025 14:21:32 GMT, Tatsunori Uchino  wrote:

>> I believe that after:
>> https://github.com/openjdk/jdk/pull/24738
>> the `stdin.encoding` property is set when the process is connected to a console, which is probably the main case where the encoding can be detected automatically.
>
> I misunderstood that I have tested `stdin.encoding`.
> I cannot confirm that `stdin.encoding` is changed in Windows to proper ones because it has not been included in the latest EA build (20) and I cannot build master for Windows. However, it is changed to `US-ASCII` in Ubuntu when I change `LANG`. I will believe its author until the latest EA build is updated.

Anyway you need to merge master first to test `stdin.encoding`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2062642061

From duke at openjdk.org  Sun Apr 27 16:58:47 2025
From: duke at openjdk.org (ExE Boss)
Date: Sun, 27 Apr 2025 16:58:47 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 26 Apr 2025 19:44:02 GMT, Chen Liang  wrote:

>> Some AccessFlag parsing methods throw IAE because a flag mask is not valid in a location. However, there is no easy way to check what flag mask bits or what flags are valid for a location. We need such APIs to check, specific to each class file format version.
>> 
>> Also in the investigation, it's noted that `ACC_SYNTHETIC` is incorrectly represented - it is available since release 5.0 instead of release 7. This bug is fixed together for implementation simplicity.
>> 
>> The new methods are all in `AccessFlag.Location`:
>> - `Set flags()`
>> - `int flagsMask()`
>> - `Set flags(ClassFileFormatVersion)`
>> - `int flagsMask(ClassFileFormatVersion)`
>> 
>> Also there is some simplification to `AccessFlag` itself to remove the anonymous classes, which should be more startup-friendly.
>> 
>> Testing: Tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix iterator missing NSEE

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 722:

> 720:     }
> 721: 
> 722:     private static final class AccessFlagSet extends AbstractSet {

This?should probably also?define the?spliterator method:

@Override
public Spliterator spliterator() {
	return Spliterators.spliterator(
		this,
		Spliterator.DISTINCT	| Spliterator.ORDERED	| Spliterator.SIZED
		| Spliterator.NONNULL	| Spliterator.IMMUTABLE	| Spliterator.SUBSIZED
	);
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23095#discussion_r2062674913

From liach at openjdk.org  Sun Apr 27 17:31:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 27 Apr 2025 17:31:47 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v8]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sun, 27 Apr 2025 16:47:59 GMT, ExE Boss  wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix iterator missing NSEE
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 722:
> 
>> 720:     }
>> 721: 
>> 722:     private static final class AccessFlagSet extends AbstractSet {
> 
> This?should probably also?define the?spliterator method:
> 
> @Override
> public Spliterator spliterator() {
> 	return Spliterators.spliterator(
> 		this,
> 		Spliterator.DISTINCT	| Spliterator.ORDERED	| Spliterator.SIZED
> 		| Spliterator.NONNULL	| Spliterator.IMMUTABLE	| Spliterator.SUBSIZED
> 	);
> }

Hmm, I intentionally avoided implementing spliterator because there are too many opportunities to optimize - a fully optimized Spliterator implementaton should split an int mask. Can we do that in another patch? I need to check if MOAT tests spliterators too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23095#discussion_r2062683681

From aturbanov at openjdk.org  Sun Apr 27 20:34:48 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 27 Apr 2025 20:34:48 GMT
Subject: RFR: 8342283: CDS cannot handle a large number of classes
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Apr 2025 14:49:37 GMT, Aleksey Shipilev  wrote:

> CDS cannot handle large number of classes, because `ClassLoader` data structures get too large for CDS archival. The new test captures such an occasion. We do `clear()`-s, but that is not enough to trim the backing storages for the affected collections.
> 
> In contrast with previous attempts to fix this (https://github.com/openjdk/jdk/pull/21797 and my VM-side field overwrite), we can just reinitialize the fields using `Unsafe`, which bypasses normal `final` field write restriction. `ClassLoader` already does a similar thing nearby! This allows us to stay fully in Java, and makes the patch fairly straightforward.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, new test reliably fails without the fix, passes with it
>  - [x] Linux x86_64 server fastdebug, `runtime/cds`

test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java line 67:

> 65:         out.add("}");
> 66:         for (int c = 0; c < NUM_NESTED_CLASSES; c++) {
> 67:             out.add("public static class " + NESTED_CLASS_NAME  + c + " {}");

Suggestion:

            out.add("public static class " + NESTED_CLASS_NAME + c + " {}");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24877#discussion_r2062715919

From duke at openjdk.org  Sun Apr 27 21:07:34 2025
From: duke at openjdk.org (fabioromano1)
Date: Sun, 27 Apr 2025 21:07:34 GMT
Subject: RFR: 8077587: BigInteger Roots [v3]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for BigIntegers using Newton method. This PR is dependent by this [PR](https://github.com/openjdk/jdk/pull/24690).

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Correct unsigned division

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/427a73e1..c8dc1a62

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 duke at openjdk.org  Sun Apr 27 21:13:59 2025
From: duke at openjdk.org (fabioromano1)
Date: Sun, 27 Apr 2025 21:13:59 GMT
Subject: RFR: 8077587: BigInteger Roots [v4]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements nth root computation for BigIntegers using Newton method. This PR is dependent by this [PR](https://github.com/openjdk/jdk/pull/24690).

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  An optimization

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/c8dc1a62..299ee6f3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 duke at openjdk.org  Mon Apr 28 00:11:47 2025
From: duke at openjdk.org (Johannes Graham)
Date: Mon, 28 Apr 2025 00:11:47 GMT
Subject: RFR: 4837946: Faster multiplication and exponentiation of large
 integers [v38]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 26 Apr 2025 21:48:25 GMT, fabioromano1  wrote:

>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Throw away unsignedIntPow(int, int)

src/java.base/share/classes/java/math/BigInteger.java line 2746:

> 2744:             if (exp <= maxExp) {
> 2745:                 // don't use fp arithmetic if exp <= 3
> 2746:                 xToExp = exp == 1 ? x :

What about pre-seeding the cache with values for 1, 2 and 3? That would allow unconditionally using fp here (and below)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2062757211

From liach at openjdk.org  Mon Apr 28 00:29:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 00:29:00 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v7]
In-Reply-To: 
References: 
Message-ID: <5CSmrJtyyc-k7hgQ1BYy82bbqSrv1g2dsyDcshk1dVY=.2a688d8c-c7f0-4fc6-90f4-5df0fe61611c@github.com>

> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
> 
> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
> 
> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
> 
> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Fix incorrect promise removal when unnecessary and add regression test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24043/files
  - new: https://git.openjdk.org/jdk/pull/24043/files/edd19537..69583b67

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=05-06

  Stats: 105 lines in 2 files changed: 70 ins; 13 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/24043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24043/head:pull/24043

PR: https://git.openjdk.org/jdk/pull/24043

From liach at openjdk.org  Mon Apr 28 00:29:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 00:29:04 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 27 Apr 2025 04:50:37 GMT, Chen Liang  wrote:

>> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
>> 
>> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
>> 
>> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
>> 
>> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Cannot test for recursion eagerly - add test case
>  - More spec, eager exception, finish with existing, thanks John
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - docs
>  - Remove the throwing behavior due to shallow reentrancy
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - Add more tests to avoid critical errors like the last one
>  - Major typo
>  - Use identity of thread, some optimizations for single thread case
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/3daf983f...edd19537

After some check, I verified the interference you have described is a preexisting bug - I have created a regression test to make sure computeValue only happens once for such an in-map (everything in-map is valid) promise.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24043#issuecomment-2833725129

From liach at openjdk.org  Mon Apr 28 01:09:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 01:09:58 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sun, 27 Apr 2025 05:28:56 GMT, John R Rose  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 12 additional commits since the last revision:
>> 
>>  - Cannot test for recursion eagerly - add test case
>>  - More spec, eager exception, finish with existing, thanks John
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>>  - docs
>>  - Remove the throwing behavior due to shallow reentrancy
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>>  - Add more tests to avoid critical errors like the last one
>>  - Major typo
>>  - Use identity of thread, some optimizations for single thread case
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/d401c31f...edd19537
>
> One thing I didn't note in the javadoc, but which might be significant, is that `computeValue` calls can be restarted for unpredictable reasons.  I gave some of them in the javadoc, but not all.  I did not document the possibility of crosstalk between  pairs.  Another pair  might do a remove and update the internal CV version.  The purpose of htis is to flush the CV cache.  But it also creates an interference with ongoing computation of `computeValue` for the original  pair.  Maybe we should treat such crosstalk as a bug.

@rose00 I ran the no-promise-removal version in tiers 1-3 and added a new test case (verified to fail on mainline with 2 computeValue invocations) for this fix. Can you review the current state of this patch and also the CSR for specification wording updates? https://bugs.openjdk.org/browse/JDK-8352433

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24043#issuecomment-2833757711

From liach at openjdk.org  Mon Apr 28 01:49:34 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 01:49:34 GMT
Subject: RFR: 8355658: Allow transforms to run on elements generated by a
 builder
Message-ID: 

Transforms can run on a stream of class file elements. Currently, that stream can only be from a CompoundElement. We can allow a ClassFileBuilder to provide such a stream too; a recent request https://mail.openjdk.org/pipermail/classfile-api-dev/2025-April/000698.html asks for this as well.

With this patch, we can now emulate this ASM pattern easily:


// ASM
ClassVisitor cv = new DelegateClassVisitor(new ClassWriter(...));
cv.visitXxx(); // write elements through the delegate

// ClassFile API
cf.build(..., clb0 -> clb0.transforming((clb, cle) -> /*process */, clb -> {
    // write elements through delegate
}));


Notably, this patch introduces a source incompatibility (but not binary) in order to allow users to call `transform(model, (xb, xe) -> {})` or `transforming((xb1, xe) -> {}, xb1 -> {})`. This has little impact if users don't use `ClassFileBuilder` as a type directly (which according to grep.app, there are only two sites on whole GitHub, both updated in this PR). A release note has been created for this incompatibility at https://bugs.openjdk.org/browse/JDK-8355665; please review too.

-------------

Commit messages:
 - 8355658: Allow transforms to run on elements generated by a builder

Changes: https://git.openjdk.org/jdk/pull/24908/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24908&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355658
  Stats: 301 lines in 11 files changed: 206 ins; 26 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/24908.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24908/head:pull/24908

PR: https://git.openjdk.org/jdk/pull/24908

From liach at openjdk.org  Mon Apr 28 04:12:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 04:12:03 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v8]
In-Reply-To: 
References: 
Message-ID: <-URvYrp9EyFasdRQatbyCU2qAo5UpnOXiXliBfNzTa4=.e2651b6e-6d61-40a4-aaa4-6c57f5a32a4b@github.com>

> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
> 
> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
> 
> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
> 
> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Test updates - remove repetition, test case for no stale installation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24043/files
  - new: https://git.openjdk.org/jdk/pull/24043/files/69583b67..8d0f26d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=06-07

  Stats: 81 lines in 1 file changed: 57 ins; 15 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/24043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24043/head:pull/24043

PR: https://git.openjdk.org/jdk/pull/24043

From liach at openjdk.org  Mon Apr 28 04:32:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 04:32:48 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v2]
In-Reply-To: 
References: 
 <9yknKYCR2xdWz_WAU7ZLbrS7KNYhq4E-FhqiKBylu5o=.159e2fb5-4fb8-4535-88c5-03412f7df988@github.com>
 
Message-ID: 

On Fri, 21 Mar 2025 13:44:17 GMT, Jaikiran Pai  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 four additional commits since the last revision:
>> 
>>  - Use identity of thread, some optimizations for single thread case
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>>  - Track threads on the promise for cheap reentrancy checks
>>  - 8351996: Alternative way to ensure no stale values for ClassValue::remove
>
> Hello Chen, not a review of the code, but the tier1 failures in the GitHub actions jobs look related:
> 
> 
> java.lang.StackOverflowError: Recursive initialization of class value
> 	at java.base/java.lang.ClassValue$Entry.registerExtraThread(ClassValue.java:321)
> 	at java.base/java.lang.ClassValue$ClassValueMap.startEntry(ClassValue.java:481)
> 	at java.base/java.lang.ClassValue.getFromHashMap(ClassValue.java:196)
> 	at java.base/java.lang.ClassValue.getFromBackup(ClassValue.java:183)
> 	at java.base/java.lang.ClassValue.get(ClassValue.java:119)

@jaikiran Since you have looked at this patch and used CountDownLatch frequently before, I wonder if you would like to review the use of concurrency utilities in this patch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24043#issuecomment-2833952397

From liach at openjdk.org  Mon Apr 28 04:33:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 04:33:49 GMT
Subject: RFR: 8355658: Allow transforms to run on elements generated by a
 builder
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Apr 2025 01:43:32 GMT, Chen Liang  wrote:

> Transforms can run on a stream of class file elements. Currently, that stream can only be from a CompoundElement. We can allow a ClassFileBuilder to provide such a stream too; a recent request https://mail.openjdk.org/pipermail/classfile-api-dev/2025-April/000698.html asks for this as well.
> 
> With this patch, we can now emulate this ASM pattern easily:
> 
> 
> // ASM
> ClassVisitor cv = new DelegateClassVisitor(new ClassWriter(...));
> cv.visitXxx(); // write elements through the delegate
> 
> // ClassFile API
> cf.build(..., clb0 -> clb0.transforming((clb, cle) -> /*process */, clb -> {
>     // write elements through delegate
> }));
> 
> 
> Notably, this patch introduces a source incompatibility (but not binary) in order to allow users to call `transform(model, (xb, xe) -> {})` or `transforming((xb1, xe) -> {}, xb1 -> {})`. This has little impact if users don't use `ClassFileBuilder` as a type directly (which according to grep.app, there are only two sites on whole GitHub, both updated in this PR). A release note has been created for this incompatibility at https://bugs.openjdk.org/browse/JDK-8355665; please review too.

Testing: tier 1-3 passed

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24908#issuecomment-2833954434

From iklam at openjdk.org  Mon Apr 28 05:16:07 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 28 Apr 2025 05:16:07 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v5]
In-Reply-To: 
References: 
Message-ID: 

> This PR contains 2 parts
> 
> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.
> 
> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):
> 
> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 
> 
> `ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:
> 
> - If an entry has not yet been collected, we make sure it will never be collected.
> - If an entry has been collected, we remove it from the table
> 
> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.
> 
> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.
> 
> In the future, we may relax the implementation to allow for other use cases.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @DanHeidinga comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24757/files
  - new: https://git.openjdk.org/jdk/pull/24757/files/bba16eef..a25aab03

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24757&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24757&range=03-04

  Stats: 8 lines in 4 files changed: 3 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24757/head:pull/24757

PR: https://git.openjdk.org/jdk/pull/24757

From iklam at openjdk.org  Mon Apr 28 05:16:08 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 28 Apr 2025 05:16:08 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 25 Apr 2025 19:17:51 GMT, Dan Heidinga  wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @fisk comment
>
> src/hotspot/share/cds/aotReferenceObjSupport.cpp line 76:
> 
>> 74: // the use of Weak/Soft references used by java.lang.invoke.
>> 75: //
>> 76: // We intent to evolve the implementation in the future by
> 
> Suggestion:
> 
> // We intend to evolve the implementation in the future by

Fixed.

> src/java.base/share/classes/jdk/internal/misc/CDS.java line 93:
> 
>> 91: 
>> 92: 
>> 93:     private static ArrayList keepAliveList;
> 
> Is it worth adding a comment stating this list should only be populated during an assembly phase?  That it should be null in both training and production runs?

I added comments and asserts for clarification.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2062899404
PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2062899353

From iklam at openjdk.org  Mon Apr 28 05:31:46 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 28 Apr 2025 05:31:46 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 25 Apr 2025 19:39:01 GMT, Dan Heidinga  wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @fisk comment
>
> src/hotspot/share/cds/aotReferenceObjSupport.cpp line 106:
> 
>> 104:     assert(CDSConfig::allow_only_single_java_thread(), "Required");
>> 105: 
>> 106:     TempNewSymbol method_name = SymbolTable::new_symbol("prepareForAOTCache");
> 
> I'm slightly uncomfortable with using the same method name (`prepareForAOTCache`) on MethodType and on ReferenceKeyMap & ReferenceKeySet as they have different expected use cases.  The one on MT is the "front door" the VM calls to remove stale Reference objects while the RKMap/RKSet are internal mechanisms that the VM would never call except for MT triggering it.
> 
> Does it make sense to use different names for these methods?  The MT one is a hook that could be extended to other classes to prepare them for cache creation while we wouldn't treat the RKMap/RKSet ones in the same way.  Maybe append "_internal" or "_helper" to the RFMap/Set methods to distinguish them?

In my mind, `MethodType::prepareForAOTCache()` makes sure all data used by `MethodType` are ready to be cached. `ReferenceKeySet::prepareForAOTCache()` does the same for this particular `ReferenceKeySet` instance.

Potentially we could have


class MethodType {
    static void prepareForAOTCache() {
        table1.prepareForAOTCache();
        table2.prepareForAOTCache();
        ....
    }
}


We can have many levels of `prepareForAOTCache()` calls where each level delegates the operations to its sub-components. There are no obvious "frontend/backend" or "interface/implementation" boundaries.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2062910787

From epeter at openjdk.org  Mon Apr 28 06:49:55 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 28 Apr 2025 06:49:55 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 25 Apr 2025 07:24:15 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 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:
> 
>  - Addressed some review comments
>    
>    1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
>    2. Improve code comments.
>  - Merge branch 'master' into JDK-8354242
>  - Merge branch 'master' into JDK-8354242
>  - 8354242: VectorAPI: combine vector not operation with compare
>    
>    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	2...

Just a drive-by comment for now, I may review this later more fully.

> I would also prefer if you added the IR restrictions rather than the JTREG requires.
The benefit is that we can still run the tests on all platforms, at least for result verification.
>
> Imagine someone adds optimizations to a new platform, but does not know about this test here. They make a mistake, and there is a bug, leading either to a crash or wrong result. With the requires, you test would never even run, and we would not catch it. With the IR applyIf, we would catch the bug.

Just copy pasting the IR applyIf everywhere is not that much work, and adding in a new platform later is not really hard either.

-------------

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24674#pullrequestreview-2798141911

From epeter at openjdk.org  Mon Apr 28 06:49:56 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 28 Apr 2025 06:49:56 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v2]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Sun, 27 Apr 2025 10:09:48 GMT, erifan  wrote:

>> I don't see XorVMask implemented on all non-x86 target, like PPC etc..
>
> This is not specifically required on x86, but because this test fails on x86 when `-XX:UseAVX=0` is specified. When `-XX:UseAVX=0` is specified, the sub-graph is like this:
> `(XorV (VectorMaskCmp (LoadVector ...)) (Replicate -1))`
> It is not an optimization pattern supported by this patch because we don't know what's the comparison op.

I would also prefer if you added the IR restrictions rather than the JTREG requires.
The benefit is that we can still run the tests on all platforms, at least for result verification.

Imagine someone adds optimizations to a new platform, but does not know about this test here. They make a mistake, and there is a bug, leading either to a crash or wrong result. With the requires, you test would never even run, and we would not catch it. With the IR applyIf, we would catch the bug.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2062988123

From pminborg at openjdk.org  Mon Apr 28 07:14:48 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 28 Apr 2025 07:14:48 GMT
Subject: RFR: 8355636: Reuse StringBuilder in printStackTrace [v7]
In-Reply-To: 
References: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
 
Message-ID: <4AW7BRpybnKumi3zcfMO-b7GLnd6nNqFvokvmOPlAmc=.046ce911-3c85-40e8-aedc-e5cda036b45e@github.com>

On Sat, 26 Apr 2025 22:42:08 GMT, Shaojin Wen  wrote:

>> In the Throwable::printStackTrace method, StringBuilder is created multiple times to build String. By sharing StringBuilder to build String, object allocation and copying are reduced.
>> 
>> In the scenario without suppressed and ourCause, unused IdentityHashMap is not created.
>> 
>> Through these optimizations, the performance of `new Exception().printStackTrace()` can be improved by about 10%.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/Throwable.java
>   
>   Co-authored-by: Hendrik Schick <30866028+ky0n at users.noreply.github.com>

As pointed out by several reviewers above, the weighted overall benefit of this PR might be negative. Reviewers carefully need to weigh pros and cons in a plurality of dimensions, including, but not limited to:

 * Consensus in pre-communicated suggestions on the relevant mailing list
 * Readability
 * Complexity
 * Integrity
 * Maintainability
 * Adherent to current and future features
 * Test coverage and testability
 * Reviewer utilization (i.e., value over other potentially more important issues to review)
 * Archaeology
 * Performance
 * Resource utilization
 
You need to up-level and address questions like this before it becomes meaningful to spend reviewing resources on this and similar PRs.

Hence, I am expecting comments rather than code from you @wenshao  in this PR until we have established that the net benefit of this PR (contrary to the beliefs of many reviewers) can ever be positive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24864#issuecomment-2834195602

From asotona at openjdk.org  Mon Apr 28 07:24:46 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 28 Apr 2025 07:24:46 GMT
Subject: RFR: 8342206: Convenience method to check if a constant pool entry
 matches nominal descriptors [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 25 Apr 2025 16:36:53 GMT, Chen Liang  wrote:

>> The ClassFile API promotes usage of constant nominal descriptors over literal strings. However, for `class` file parsing, currently the efficient way to check if a constant pool entry matches a desired descriptor is via unrolling them back to strings. However, string unrolling is ugly, and often times confusing, such as internal names versus field descriptors.
>> 
>> As a result, I propose to provide new methods that compare constant pool entries with the potential symbolic descriptors they represent. This is no less efficient as checking raw string equality, avoids exceptional failure behaviors of conversion to symbolic descriptors, and avoids potential programmer errors stemming from raw string handling. See the CSR for a full story.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Extract the actual tests, move pool entry spawning to the bottom
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cf-equals-sym
>  - Rename UTF8 test methods to be different from other test methods
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cf-equals-sym
>  - 8342206: Convenience method to check if a constant pool entry matches nominal descriptors

ConstantDescSymbolsTest looks a bit better now.
Thank you.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23548#pullrequestreview-2798229279

From duke at openjdk.org  Mon Apr 28 07:31:49 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 28 Apr 2025 07:31:49 GMT
Subject: RFR: 4837946: Faster multiplication and exponentiation of large
 integers [v38]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 28 Apr 2025 00:09:28 GMT, Johannes Graham  wrote:

> What about pre-seeding the cache with values for 1, 2 and 3? That would allow unconditionally using fp here (and below)

It's a good idea, but doing so would increase the already high dependence of `computePower()` by the preconditions given by `unsignedLongPow()`, so at this point I wonder if it will still make sense to maintain the code separated, rather than putting it in `unsignedLongPow()` and throw away `computePower()`...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2063050038

From asotona at openjdk.org  Mon Apr 28 07:38:47 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 28 Apr 2025 07:38:47 GMT
Subject: RFR: 8341275: Explicit counter support for Code attribute building
 [v2]
In-Reply-To: <0QEX0NA3qOGsRadwDcp42BhyOeZl09677eskI00x7Lo=.bd667709-7c30-4489-8013-411326e63813@github.com>
References: 
 <0QEX0NA3qOGsRadwDcp42BhyOeZl09677eskI00x7Lo=.bd667709-7c30-4489-8013-411326e63813@github.com>
Message-ID: 

On Sun, 27 Apr 2025 03:38:35 GMT, Chen Liang  wrote:

>> Internal explicit counter support for Code max_stack and max_locals has been already added in #24807. Since that example works well, we may consider opening this functionality up to general users under strict restrictions.
>> 
>> This is an advanced API; thus, I chose a more complex name `withExplicitStackAndLocals` that discourages accidental use, and indicates the exact order of stack and locals arguments. For integrity, the argument checks are unconditional. And this is also barred behind `DROP_STACK_MAPS` advanced option.
>> 
>> I have enhanced the tests with a `CodeBuilderType` utility to test all types of code builders; it is already effective at increasing coverage in some of our existing tests that only cover DirectCodeBuilder, and simplify other tests. It is particularly helpful for my new `BuilderExplicitMaxsTest`.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust indents

Stack counter already serves to very limited set of use cases. 
In a hunt for the maximum JDK performance  #24705 called specific implementation method and saved some CPU cycles by setting explicit maxLocals and maxStack in the SwitchBootstraps.
However I'm not sure this single corner case of the corner cases is enough to make it a public API.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24903#issuecomment-2834250345

From duke at openjdk.org  Mon Apr 28 07:48:55 2025
From: duke at openjdk.org (erifan)
Date: Mon, 28 Apr 2025 07:48:55 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v2]
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: 

On Mon, 28 Apr 2025 06:45:58 GMT, Emanuel Peter  wrote:

>> This is not specifically required on x86, but because this test fails on x86 when `-XX:UseAVX=0` is specified. When `-XX:UseAVX=0` is specified, the sub-graph is like this:
>> `(XorV (VectorMaskCmp (LoadVector ...)) (Replicate -1))`
>> It is not an optimization pattern supported by this patch because we don't know what's the comparison op.
>
> I would also prefer if you added the IR restrictions rather than the JTREG requires.
> The benefit is that we can still run the tests on all platforms, at least for result verification.
> 
> Imagine someone adds optimizations to a new platform, but does not know about this test here. They make a mistake, and there is a bug, leading either to a crash or wrong result. With the requires, you test would never even run, and we would not catch it. With the IR applyIf, we would catch the bug.

I can make the change, it's not complex, but it is different from what I thought before.

I thought that supporting vector was the default behavior, is it right? So when I was doing an architecture-independent feature or optimization, I should just exclude those unsupported cases from the test, so that all potential environments would be tested. If I was doing an architecture- or feature-dependent optimization, then I should limit the test to run only in supported environments.

For this case, **the current meaning of @requires is "skip this test when -XX:UseAVX=0 is specified on the x86 architecture, otherwise run the tests".** So if a new architecture (say s390) supports related vector operations in the future, then this test will be run on that platform by default.

If all architecture-independent tests are restricted with applyIfCPUFeatureOr, then when we support a new architecture, we will need to modify all tests, otherwise no test will run on this architecture.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2063076640

From duke at openjdk.org  Mon Apr 28 07:51:55 2025
From: duke at openjdk.org (erifan)
Date: Mon, 28 Apr 2025 07:51:55 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 28 Apr 2025 06:47:38 GMT, Emanuel Peter  wrote:

> Just a drive-by comment for now, I may review this later more fully.
> 
> > I would also prefer if you added the IR restrictions rather than the JTREG requires.
> > The benefit is that we can still run the tests on all platforms, at least for result verification.
> > Imagine someone adds optimizations to a new platform, but does not know about this test here. They make a mistake, and there is a bug, leading either to a crash or wrong result. With the requires, you test would never even run, and we would not catch it. With the IR applyIf, we would catch the bug.
> 
> Just copy pasting the IR applyIf everywhere is not that much work, and adding in a new platform later is not really hard either.

Thanks! The problem is that when a new platform is added, people may not even know there is a test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-2834280547

From swen at openjdk.org  Mon Apr 28 07:52:54 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 28 Apr 2025 07:52:54 GMT
Subject: RFR: 8355636: Reuse StringBuilder in printStackTrace [v7]
In-Reply-To: 
References: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
 
Message-ID: 

On Sat, 26 Apr 2025 22:42:08 GMT, Shaojin Wen  wrote:

>> In the Throwable::printStackTrace method, StringBuilder is created multiple times to build String. By sharing StringBuilder to build String, object allocation and copying are reduced.
>> 
>> In the scenario without suppressed and ourCause, unused IdentityHashMap is not created.
>> 
>> Through these optimizations, the performance of `new Exception().printStackTrace()` can be improved by about 10%.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/Throwable.java
>   
>   Co-authored-by: Hendrik Schick <30866028+ky0n at users.noreply.github.com>

Because more than one Reviewer disagrees with the changes in this PR, I have closed this PR. Thank you for the reviewers who spent time on this PR. Thank you for your time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24864#issuecomment-2834284078

From swen at openjdk.org  Mon Apr 28 07:52:55 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 28 Apr 2025 07:52:55 GMT
Subject: Withdrawn: 8355636: Reuse StringBuilder in printStackTrace
In-Reply-To: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
References: <5HW7pRgkw_-nh69lpntRopQh9P7lwmu0E9XjnOWetuo=.715b2b57-0480-40da-8087-424cd67e7a14@github.com>
Message-ID: 

On Fri, 25 Apr 2025 01:36:50 GMT, Shaojin Wen  wrote:

> In the Throwable::printStackTrace method, StringBuilder is created multiple times to build String. By sharing StringBuilder to build String, object allocation and copying are reduced.
> 
> In the scenario without suppressed and ourCause, unused IdentityHashMap is not created.
> 
> Through these optimizations, the performance of `new Exception().printStackTrace()` can be improved by about 10%.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24864

From mcimadamore at openjdk.org  Mon Apr 28 08:35:53 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 28 Apr 2025 08:35:53 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
References: 
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
Message-ID: 

On Wed, 23 Apr 2025 00:56:18 GMT, Jiangli Zhou  wrote:

>> Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
>> 
>> `NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.
>> 
>> In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
>  - Address henryjen@ comment:
>    - Remove '#include '.

Looks good to me -- but also risky. I'd prefer if @JornVernee could also take a look.

The changes here look good. Essentially, if `syslookup` is statically linked, trying to do a `dlopen` on it will fail, as the shared library for it doesn't exist. For this reason, this PR seems to "upgrade" syslookup to a JNI library. The presence of the `JNI_OnLoad_syslookup` is then used, as per [JEP 178](https://openjdk.org/jeps/178) to determine whether `syslookup` is a "builtin" library -- that is, a library for which no dynamic linking should occur.

The loaded library is associated with the boot classloader. This could be problematic, in principle. However, since the requests to `loadLibrary` also come from the boot loader (they are from the `SystemLookup` class) it all works out ok.

Having to upgrade to JNI is a bit sad -- although I get that it is required as a workaround for now. For the longer term I'd prefer a better way to integrate static lookups in the FFM API. For instance, all `JNI::loadLibrary` does when it comes to static libraries is to return the so called "process handle" -- e.g. a handle to the running process (the JVM). If there was a way to retrieve such a handle (e.g. via a dedicated `SymbolLookup` factory) it would be possible to avoid the JNI dance: just get the process symbol lookup, and look for statically linked symbols in there.

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24801#pullrequestreview-2798483910
PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2834427351

From pminborg at openjdk.org  Mon Apr 28 08:36:18 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 28 Apr 2025 08:36:18 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v78]
In-Reply-To: 
References: 
 
 
Message-ID: <-5FmKjBNDTWQWE532XDpXXz1wymHO7mhjEEai6dhqQg=.934cf1a2-d716-49e7-870b-500060834bf2@github.com>

On Thu, 24 Apr 2025 23:53:11 GMT, Luca Kellermann  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make public constuctor private
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 898:
> 
>> 896:                 final StableValueImpl[] reversed = ArraysSupport.reverse(
>> 897:                         Arrays.copyOf(delegates, delegates.length));
>> 898:                 return StableUtil.renderElements(base, "Collection", reversed);
> 
> Suggestion:
> 
>                 return StableUtil.renderElements(this, "StableList", reversed);
> 
> All other calls use "Stable...". Other view collections (`ArrayList.SubList`, `ReverseOrderListView`, `AbstractMap.keySet`, `AbstractMap.values`, `HashMap.EntrySet`) use the view reference (and not the underlying collection) for detecting self containment, so `renderElements` should use `this` instead of `base` for `self`.

The reason we are using "Collection" is that this method directly overrides `AbstractCollection` which is using "(this Collection)" for first-level circular references. I also think `base` should be replaced with `this`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2063177736

From jlahoda at openjdk.org  Mon Apr 28 08:59:09 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 28 Apr 2025 08:59:09 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v6]
In-Reply-To: 
References: 
Message-ID: 

> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
> - `java. ... .IO` is no longer automatically imported in any compilation unit
> - the feature is finalized (i.e. no longer requires `--enable-preview`)

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:

 - Merge branch 'master' into finalize-concise-source-files
 - Merge remote-tracking branch 'origin/finalize-concise-source-files' into finalize-concise-source-files
 - Add clause about handling of malformed/unmappable bytes.
 - Rewrite bits about charset decoding, removing mention of "internal objects."
 - Use local variable for System.out in print().
 - Reverting test commit.
   
   This reverts commit 7047cf007cc7de937aa21e96125083ee92932692.
 - Fixing tests.
 - Updating copyright year.
 - Adding bug number to tests.
 - Fixing IO tests path
 - ... and 27 more: https://git.openjdk.org/jdk/compare/cd6f0d19...e9f931b2

-------------

Changes: https://git.openjdk.org/jdk/pull/24438/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=05
  Stats: 1021 lines in 57 files changed: 303 ins; 585 del; 133 mod
  Patch: https://git.openjdk.org/jdk/pull/24438.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24438/head:pull/24438

PR: https://git.openjdk.org/jdk/pull/24438

From viktor.klang at oracle.com  Mon Apr 28 09:02:29 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 28 Apr 2025 09:02:29 +0000
Subject: Casting gatherer
In-Reply-To: 
References: 
Message-ID: 

The challenge here is that there is no, current, reification of a pattern application, so all it boils down to at this point is: given a Predicate for some type T, make a cast to some unrelated type R.

For Class-based retention of elements, it is possible to do the equivalent of testing Class::isInstance(element) and then push the element downstream after a Class::cast(element)

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev  on behalf of Nir Lisker 
Sent: Saturday, 26 April 2025 20:55
To: core-libs-dev at openjdk.org 
Subject: Casting gatherer

Hi,

instanceof has been refitted to include an auto-cast ("pattern matching on instanceof"). Unfortunately, doing this as an intermediate operation on a stream requires first to filter via instanceof and then map via a cast. This is because

    x instanceof MyClass myClass

returns a boolean, not myClass.

I've asked for an easier way of doing it long ago directly on Stream and was declined, but now with Gatherers I'm bringing this up again. I think it would be reasonable to put such an operation in the Gatherers class. I imagine that many Gatherer libraries, or utility classes, will include it since it's a common operation, and having it in the JDK means that it'll be done the best way possible (you can optimize where others can't, if applicable here).

-- Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From shade at openjdk.org  Mon Apr 28 09:20:38 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Apr 2025 09:20:38 GMT
Subject: RFR: 8342283: CDS cannot handle a large number of classes [v2]
In-Reply-To: 
References: 
Message-ID: 

> CDS cannot handle large number of classes, because `ClassLoader` data structures get too large for CDS archival. The new test captures such an occasion. We do `clear()`-s, but that is not enough to trim the backing storages for the affected collections.
> 
> In contrast with previous attempts to fix this (https://github.com/openjdk/jdk/pull/21797 and my VM-side field overwrite), we can just reinitialize the fields using `Unsafe`, which bypasses normal `final` field write restriction. `ClassLoader` already does a similar thing nearby! This allows us to stay fully in Java, and makes the patch fairly straightforward.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, new test reliably fails without the fix, passes with it
>  - [x] Linux x86_64 server fastdebug, `runtime/cds`

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:

 - Minor touchup
 - Merge branch 'master' into JDK-8342283-cds-many-classes
 - Adjust TEST.groups
 - Fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24877/files
  - new: https://git.openjdk.org/jdk/pull/24877/files/97ab42b6..d45ecd2f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24877&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24877&range=00-01

  Stats: 5902 lines in 267 files changed: 3247 ins; 1104 del; 1551 mod
  Patch: https://git.openjdk.org/jdk/pull/24877.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24877/head:pull/24877

PR: https://git.openjdk.org/jdk/pull/24877

From shade at openjdk.org  Mon Apr 28 09:20:40 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Apr 2025 09:20:40 GMT
Subject: RFR: 8342283: CDS cannot handle a large number of classes [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 27 Apr 2025 20:32:24 GMT, Andrey Turbanov  wrote:

>> 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:
>> 
>>  - Minor touchup
>>  - Merge branch 'master' into JDK-8342283-cds-many-classes
>>  - Adjust TEST.groups
>>  - Fix
>
> test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java line 67:
> 
>> 65:         out.add("}");
>> 66:         for (int c = 0; c < NUM_NESTED_CLASSES; c++) {
>> 67:             out.add("public static class " + NESTED_CLASS_NAME  + c + " {}");
> 
> Suggestion:
> 
>             out.add("public static class " + NESTED_CLASS_NAME + c + " {}");

Fixed, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24877#discussion_r2063255718

From epeter at openjdk.org  Mon Apr 28 09:20:46 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 28 Apr 2025 09:20:46 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 28 Apr 2025 07:48:58 GMT, erifan  wrote:

> > Just a drive-by comment for now, I may review this later more fully.
> > > I would also prefer if you added the IR restrictions rather than the JTREG requires.
> > > The benefit is that we can still run the tests on all platforms, at least for result verification.
> > > Imagine someone adds optimizations to a new platform, but does not know about this test here. They make a mistake, and there is a bug, leading either to a crash or wrong result. With the requires, you test would never even run, and we would not catch it. With the IR applyIf, we would catch the bug.
> > 
> > 
> > Just copy pasting the IR applyIf everywhere is not that much work, and adding in a new platform later is not really hard either.
> 
> Thanks! The problem is that when a new platform is added, people may not even know there is a test.

@erifan That is true. But we have that problem either way. If you use `@require`, then the person does not realize there is a test AND the test is not run. If you use `applyIf`, the person does not realize there is a test, but it is run at least for result verifiation - and then the person MIGHT realize if the test catches a wrong result / crash.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-2834565901

From shade at openjdk.org  Mon Apr 28 09:30:47 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Apr 2025 09:30:47 GMT
Subject: RFR: 8342283: CDS cannot handle a large number of classes [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 25 Apr 2025 20:54:21 GMT, John R Rose  wrote:

>> 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:
>> 
>>  - Minor touchup
>>  - Merge branch 'master' into JDK-8342283-cds-many-classes
>>  - Adjust TEST.groups
>>  - Fix
>
> src/java.base/share/classes/java/lang/ClassLoader.java line 2590:
> 
>> 2588:      * @implNote This is done while the JVM is running in single-threaded mode,
>> 2589:      * and at the very end of Java bytecode execution. We know that no more classes
>> 2590:      * will be loaded and none of the fields modified by this method will be used again.
> 
> There is a tiny technical debt here.  If future AOT code generation uses a future aggressive constant folding of object fields (cf. `TrustFinalNonStaticFields`) and a constant CL reference ends up in optimized code and there is a constant-folded reference (and.. and?) it is remotely possible that the old value of the field will get wrongly embedded in AOT code.
> 
> If we arrange AOT code generation to occur after all of these fixups (in Java code) are done, then the problem will not occur.  It's a delicate set of invariants.  Your expanded comment is a good start at calling them out, but this is a long string we are pulling on.

(I borrowed this comment from the initial @iklam's PR, so I need to credit him as contributor.)

Yes, CDS does awkward state manipulations at dump time. Resetting the states of final/`@Stable` objects can run into issues that you described. I think this is one of the reasons why Leyden generates AOT code with `-XX:-FoldStableValues`:

https://github.com/openjdk/leyden/blob/885096a8b3194371cde6b96ce5554d89f99618d7/src/hotspot/share/code/aotCodeCache.cpp#L162

I would guess we need to do the same with `TrustFinalNonStaticFields`. The awkward part of current  `trust_final_non_static_fields()` code is that it implicitly trusts things in `java/lang`, even with `-TrustFinalNonStaticFields`. That sounds like something we need to rectify for Leyden AOT code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24877#discussion_r2063277934

From asotona at openjdk.org  Mon Apr 28 09:33:48 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 28 Apr 2025 09:33:48 GMT
Subject: RFR: 8355658: Allow transforms to run on elements generated by a
 builder
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Apr 2025 01:43:32 GMT, Chen Liang  wrote:

> Transforms can run on a stream of class file elements. Currently, that stream can only be from a CompoundElement. We can allow a ClassFileBuilder to provide such a stream too; a recent request https://mail.openjdk.org/pipermail/classfile-api-dev/2025-April/000698.html asks for this as well.
> 
> With this patch, we can now emulate this ASM pattern easily:
> 
> 
> // ASM
> ClassVisitor cv = new DelegateClassVisitor(new ClassWriter(...));
> cv.visitXxx(); // write elements through the delegate
> 
> // ClassFile API
> cf.build(..., clb0 -> clb0.transforming((clb, cle) -> /*process */, clb -> {
>     // write elements through delegate
> }));
> 
> 
> Notably, this patch introduces a source incompatibility (but not binary) in order to allow users to call `transform(model, (xb, xe) -> {})` or `transforming((xb1, xe) -> {}, xb1 -> {})`. This has little impact if users don't use `ClassFileBuilder` as a type directly (which according to grep.app, there are only two sites on whole GitHub, both updated in this PR). A release note has been created for this incompatibility at https://bugs.openjdk.org/browse/JDK-8355665; please review too.

Actual workaround for the above pattern is:

cf.transformClass(cf.parse(cf.build(...)), (clb, cle) -> /*process */, clb -> {
    // write elements through delegate
});

Instead of breaking the actual Class-File API compatibility and introduction of a new complex build&transform pattern
I would rather propose a new API method(s) ``ClassFile::buildToModel``.
However only if there is a strong request to optimize the process (to avoid redundant build/parse spin).

``CodeBuilder::transforming`` was never intended as a general pattern for all elements on all levels. Code building is the only exception providing intermediate transformation. Code building needs to handle situations where the actually built code must be immediately transformed in order to make the code valid to successfully finish the build process. This approach is not necessary on other building levels (class, method or field builder).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24908#issuecomment-2834600671

From duke at openjdk.org  Mon Apr 28 09:53:46 2025
From: duke at openjdk.org (erifan)
Date: Mon, 28 Apr 2025 09:53:46 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v3]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Mon, 28 Apr 2025 09:17:58 GMT, Emanuel Peter  wrote:

> > > Just a drive-by comment for now, I may review this later more fully.
> > > > I would also prefer if you added the IR restrictions rather than the JTREG requires.
> > > > The benefit is that we can still run the tests on all platforms, at least for result verification.
> > > > Imagine someone adds optimizations to a new platform, but does not know about this test here. They make a mistake, and there is a bug, leading either to a crash or wrong result. With the requires, you test would never even run, and we would not catch it. With the IR applyIf, we would catch the bug.
> > > 
> > > 
> > > Just copy pasting the IR applyIf everywhere is not that much work, and adding in a new platform later is not really hard either.
> > 
> > 
> > Thanks! The problem is that when a new platform is added, people may not even know there is a test.
> 
> @erifan That is true. But we have that problem either way. If you use `@require`, then the person does not realize there is a test AND the test is not run. If you use `applyIf`, the person does not realize there is a test, but it is run at least for result verifiation - and then the person MIGHT realize if the test catches a wrong result / crash.

This test will run on new platforms when we use @requires. I explained the meaning of the @requires in the previous comment, it only excludes one case: when -XX:UseAVX=0 is specified on x86 platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-2834650280

From nlisker at gmail.com  Mon Apr 28 11:21:16 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Mon, 28 Apr 2025 14:21:16 +0300
Subject: Casting gatherer
In-Reply-To: 
References: 
 
Message-ID: 

Hi Viktor,

stream.filter(myClass:isInstance).map(myClass:cast)

is indeed the current way of doing it. I've written this code many times
and I suspect others have too. An extracted version might reside in many
utility classes. This is why I suggested having a Gatherer for it in
Gatherers. I've written a naive implementation:

private static  Gatherer filterCast(Class type) {
    return Gatherer.of(
        (_, element, downstream) -> {
            if (type.isInstance(element)) {
                return downstream.push(type.cast(element));
            }
            return true;
        }
    );
}

which we might start seeing in gatherer libraries.

We don't need to be able to write 'x instanceof T', although it would be
useful in many cases. It's a discussion for Valhalla. Valhalla will also
allow us to use this for "non-class based" elements when generics over
primitives arrive, so this gatherer is no different than the others.

As noted above, Amber might offer solutions too. Obviously, lower-level
solutions from Valhalla and Amber are preferable, but I don't know what the
plans are. Maybe you can discuss this internally. Otherwise, do you think
this is a good fit?

-- Nir

On Mon, Apr 28, 2025 at 12:02?PM Viktor Klang 
wrote:

> The challenge here is that there is no, current, reification of a pattern
> application, so all it boils down to at this point is: given a Predicate
> for some type T, make a cast to some unrelated type R.
>
> For Class-based retention of elements, it is possible to do the equivalent
> of testing Class::isInstance(element) and then push the element downstream
> after a Class::cast(element)
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev  on behalf of Nir
> Lisker 
> *Sent:* Saturday, 26 April 2025 20:55
> *To:* core-libs-dev at openjdk.org 
> *Subject:* Casting gatherer
>
> Hi,
>
> instanceof has been refitted to include an auto-cast ("pattern matching on
> instanceof"). Unfortunately, doing this as an intermediate operation on a
> stream requires first to filter via instanceof and then map via a cast.
> This is because
>
>     x instanceof MyClass myClass
>
> returns a boolean, not myClass.
>
> I've asked for an easier way of doing it long ago directly on Stream and
> was declined, but now with Gatherers I'm bringing this up again. I think it
> would be reasonable to put such an operation in the Gatherers class. I
> imagine that many Gatherer libraries, or utility classes, will include it
> since it's a common operation, and having it in the JDK means that it'll be
> done the best way possible (you can optimize where others can't, if
> applicable here).
>
> -- Nir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mcimadamore at openjdk.org  Mon Apr 28 11:33:06 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 28 Apr 2025 11:33:06 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33]
In-Reply-To: 
References: 
 
 
 <3arhaBIc5A-NbGpFZ_ehEMQhTzXSeIlel9cFNWwg9gE=.a1f457a0-ed07-4016-82ea-bace156ff4e9@github.com>
 
 
 
Message-ID: 

On Wed, 23 Apr 2025 07:38:00 GMT, Viktor Klang  wrote:

>> I asked around/looked this up, and it seems 'contents' would be more correct here, since a StableValue is primarily a container of things (you put things into it, get things out).
>
> Yeah, that was what I was thinking too.

Note - the JEP uses the word `content` (which has, I think, been "vetted"). So I believe it would be ok (and, preferrable) to leave it as is. Unless you are suggesting to also update the JEP?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2063470471

From mcimadamore at openjdk.org  Mon Apr 28 11:53:47 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 28 Apr 2025 11:53:47 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v2]
In-Reply-To: 
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 
Message-ID: 

On Fri, 18 Apr 2025 18:25:54 GMT, Chen Liang  wrote:

>> Perf numbers for simple main:
>> Linking of `Class::forName0` down from ~152 to ~83
>> 
>> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
>> JNI: ~45
>> baseline panama: ~164
>> patch: ~103
>> 
>> Also see #24705.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify FFM linker warmup

src/java.base/share/classes/jdk/internal/foreign/abi/NativeEntryPoint.java line 57:

> 55:             if (!(o instanceof CacheKey other)) return false;
> 56: 
> 57:             return methodType == other.methodType && abi == other.abi && capturedStateMask == other.capturedStateMask

Is this correct? The old code was using `MethodType::equals`, but now we seem to use `==` instead. I suppose the idea is that method types are interned, and their `equals` method is only really meaningful when checking whether a method type with same shape has already been interned?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2063500588

From liach at openjdk.org  Mon Apr 28 12:29:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 12:29:46 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v2]
In-Reply-To: 
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 
 
Message-ID: 

On Mon, 28 Apr 2025 11:51:23 GMT, Maurizio Cimadamore  wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify FFM linker warmup
>
> src/java.base/share/classes/jdk/internal/foreign/abi/NativeEntryPoint.java line 57:
> 
>> 55:             if (!(o instanceof CacheKey other)) return false;
>> 56: 
>> 57:             return methodType == other.methodType && abi == other.abi && capturedStateMask == other.capturedStateMask
> 
> Is this correct? The old code was using `MethodType::equals`, but now we seem to use `==` instead. I suppose the idea is that method types are interned, and their `equals` method is only really meaningful when checking whether a method type with same shape has already been interned?

Yep, equals are only used on primordial method types for the intern table. Identity is significant for invokers sharing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2063551903

From heidinga at openjdk.org  Mon Apr 28 12:53:46 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 28 Apr 2025 12:53:46 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: <2Gy-nNmowCMbzeMWCW2HJasKpxPfTgFwOPUScNd-ywg=.d8d8c09a-e9d9-44a1-b1f0-b4f45047f719@github.com>

On Mon, 28 Apr 2025 05:28:58 GMT, Ioi Lam  wrote:

>> src/hotspot/share/cds/aotReferenceObjSupport.cpp line 106:
>> 
>>> 104:     assert(CDSConfig::allow_only_single_java_thread(), "Required");
>>> 105: 
>>> 106:     TempNewSymbol method_name = SymbolTable::new_symbol("prepareForAOTCache");
>> 
>> I'm slightly uncomfortable with using the same method name (`prepareForAOTCache`) on MethodType and on ReferenceKeyMap & ReferenceKeySet as they have different expected use cases.  The one on MT is the "front door" the VM calls to remove stale Reference objects while the RKMap/RKSet are internal mechanisms that the VM would never call except for MT triggering it.
>> 
>> Does it make sense to use different names for these methods?  The MT one is a hook that could be extended to other classes to prepare them for cache creation while we wouldn't treat the RKMap/RKSet ones in the same way.  Maybe append "_internal" or "_helper" to the RFMap/Set methods to distinguish them?
>
> In my mind, `MethodType::prepareForAOTCache()` makes sure all data used by `MethodType` are ready to be cached. `ReferenceKeySet::prepareForAOTCache()` does the same for this particular `ReferenceKeySet` instance.
> 
> Potentially we could have
> 
> 
> class MethodType {
>     static void prepareForAOTCache() {
>         table1.prepareForAOTCache();
>         table2.prepareForAOTCache();
>         ....
>     }
> }
> 
> 
> We can have many levels of `prepareForAOTCache()` calls where each level delegates the operations to its sub-components. There are no obvious "frontend/backend" or "interface/implementation" boundaries.

We're creating a set of hooks - right now, there is one in MT - that are called by the VM at the appropriate time during the assembly phase to massage the class's state before we write the AOTCache out.

Conceptually any class could have a `prepareForAOTCache` method that would act as a front door for the VM to know how to set up its state.  

Right now we have a hard coded list of one class - MT - that we call `prepareForAOTCache` on.  Another way to implement this would be to loop through all classes that AOTCache candidates and call their `prepareForAOTCache` method (fi they have one).

If we expand this beyond MT, how does a reader of the code know which classes have VM call-in points and which don't?

(I'll mention here I missed the static modifier was only on MT which changes the argument a little but I still think different names would be clearer to diffierntiate between what the VM is expected to call and what may happen to the instances)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2063590811

From jvernee at openjdk.org  Mon Apr 28 13:07:46 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 28 Apr 2025 13:07:46 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: 
References: 
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
 
Message-ID: 

On Mon, 28 Apr 2025 08:30:43 GMT, Maurizio Cimadamore  wrote:

> Having to upgrade to JNI is a bit sad -- although I get that it is required as a workaround for now. For the longer term I'd prefer a better way to integrate static lookups in the FFM API. For instance, all `JNI::loadLibrary` does when it comes to static libraries is to return the so called "process handle" -- e.g. a handle to the running process (the JVM). If there was a way to retrieve such a handle (e.g. via a dedicated `SymbolLookup` factory) it would be possible to avoid the JNI dance: just get the process symbol lookup, and look for statically linked symbols in there.

I remember this wasn't quite as elegant on Windows, but I suppose there is already some solution in place to look up symbols that are statically linked into the same executable?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2835178681

From jd at civilian-framework.org  Mon Apr 28 13:14:02 2025
From: jd at civilian-framework.org (=?UTF-8?Q?Johannes_D=C3=B6bler?=)
Date: Mon, 28 Apr 2025 15:14:02 +0200
Subject: Namespace Prefix Issue in XML to XSL Transformation
In-Reply-To: 
References: 
Message-ID: <8a3279be-1de1-4283-8e95-2e95785a1c4e@civilian-framework.org>

Probably best to nail down the problem in a bug report first, providing 
XML input, XSLT stylesheet, actual and expected XML output to 
demonstrate the problem.
Now if https://bugs.openjdk.org/browse/JDK-8168664 describes your problem:
The Xalan version bundled with the JDK /afaik/ seems to get occasional 
security updates and improvements but does not reflect the latest Xalan 
version.
Latest Xalan 2.7.3 does not show the problematic behaviour of 
JDK-8168664, so a possible workaround would be to not rely on the XSLT 
processor bundled with the JDK but instead use Xalan or Saxon directly.

Best,
Johannes

On 23/04/2025 16:03, Hempushpa Sahu wrote:
>
> Problem Description :
>
> XSLT transformation creating unique namespace prefixes.
>
> Analysis & Observation :
>
> The XSLT transformation is generating a new namespace prefix for every 
> XML element, even when the namespace value matches that of the parent 
> element. This leads to large XML file transformations exceeding the 
> file size and memory limits on our systems.
>
> The behaviour in OpenJDK has remained consistent since JDK 8; however, 
> the namespace prefix issue is not something we find optimum.
>
> During our investigation of the OpenJDK codebase, we identified defect 
> https://bugs.openjdk.org/browse/JDK-8167179, which was intended to 
> resolve the namespace prefix issue in the OpenJDK 8 release. However, 
> our testing confirms that the issue persists across multiple versions, 
> including OpenJDK 8, 11, 17, and 22. Additionally, we found an open 
> bug report https://bugs.openjdk.org/browse/JDK-8168664 in the OpenJDK 
> issue tracker referencing a similar problem. Notably, there has been 
> no recent activity on this bug for several years
>
> Suggested Solution:
>
> Introduced a hashmap, and storing the unique namespace-url from root 
> node and checking if new url namespace-url encountered then we will 
> store it in the hashmap and increment the namespace prefix, else we 
> will not increment the prefix.
>
> Implemented in existing function startXslElement() of 
> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java
>
> ????????????? else {
>
> ??????? // Need to generate a prefix?
>
> ??????? if (namespace != null && namespace.length() > 0) {
>
> ??????????? prefix = generatePrefix();
>
> ??????????? qname = prefix + ':' + qname;
>
> ??????????? handler.startElement(namespace, qname, qname);
>
> handler.namespaceAfterStartElement(prefix, namespace);
>
> ??????? }
>
> The above code is changed to
>
> ????????????? else {
>
> ??????? // Need to generate a prefix?
>
> ???????????????????????????? if (namespace != null && 
> namespace.length() > 0) {
>
> //Check if prefix needs to be incremented.
>
> if (!namespaceMap.containsKey(namespace))
>
> {
>
> namespaceMap.put(namespace, 
> threadLocalPrefixIndex.get().getAndIncrement());
>
> prefix = "ns"+namespaceMap.get(namespace);
>
> qname = prefix + ':' + qname;
>
> handler.startElement(namespace, qname, qname);
>
> ????????????? handler.namespaceAfterStartElement(prefix, namespace);
>
> }
>
> else
>
> {
>
> //Namespace URI already exist in map.
>
> prefix = "ns"+namespaceMap.get(namespace);
>
> qname = prefix + ':' + qname;
>
> handler.startElement(namespace, qname, qname);
>
> ????????????? handler.namespaceAfterStartElement(prefix, namespace);
>
> }
>
> ???????????????????????????? }
>
> Releases:
>
> OpenJDK 8, 11, 17 & 22 the issue is seen.
>
> Note:
>
> Proceeding with this approach, we will need to update the test files. 
> For instance, we have identified one test case that validates the 
> namespace prefix in the result - 
> test/jaxp/javax/xml/jaxp/unittest/transform/NamespacePrefixTest.java
>
> Next steps:
>
> We want to take the above-mentioned fix to OpenJDK.
>
> Please review and suggest if the above understanding is right and we 
> shall take the fix to OpenJDK.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jvernee at openjdk.org  Mon Apr 28 13:24:52 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 28 Apr 2025 13:24:52 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
References: 
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
Message-ID: 

On Wed, 23 Apr 2025 00:56:18 GMT, Jiangli Zhou  wrote:

>> Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
>> 
>> `NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.
>> 
>> In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
>  - Address henryjen@ comment:
>    - Remove '#include '.

Marked as reviewed by jvernee (Reviewer).

I had a look at the implementation, and see how it works now. The JNI_OnLoad_XXX function is essentially being used as a marker to indicate that this library was statically linked into the VM binary, so we can create a `NativeLibrary` instance that is marked as 'builtin', which changes the way symbol lookups are handled.

I think the current solution is probably fine. I think alternatively we could keep track of a table with statically linked libraries to determine where/how symbols should be looked up for a particular library. Or, the symbol doesn't necessarily have to be JNI_OnLoad_XXX, but could be some other, non-JNI-specific, marker symbol.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24801#pullrequestreview-2799287975
PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2835232241

From jlahoda at openjdk.org  Mon Apr 28 13:26:30 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 28 Apr 2025 13:26:30 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v7]
In-Reply-To: 
References: 
Message-ID: 

> This is a patch to finalize the module imports feature. Please see:
> https://bugs.openjdk.org/browse/JDK-8344700

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge branch 'master' into JDK-8344708
 - Adjusting ToolProviderTest to the updated persistence handling.
 - Merge branch 'master' into JDK-8344708
 - Reflecting review feedback: cleanup formatting in ModuleInfo.
 - Reflecting review feedback - avoiding hardcoded constants.
 - Fixing test.
 - Cleanup, fixing tests.
 - Adjusting JShell defaults.
 - Fixing tests.
 - Cleanup - updated specification will permit requires transitive java.base; for all classfile versions; java.se no longer participates in preview.
 - ... and 3 more: https://git.openjdk.org/jdk/compare/1f228e55...da39d0ef

-------------

Changes: https://git.openjdk.org/jdk/pull/23801/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23801&range=06
  Stats: 432 lines in 32 files changed: 236 ins; 122 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/23801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23801/head:pull/23801

PR: https://git.openjdk.org/jdk/pull/23801

From vromero at openjdk.org  Mon Apr 28 13:38:51 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 28 Apr 2025 13:38:51 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Apr 2025 13:26:30 GMT, Jan Lahoda  wrote:

>> This is a patch to finalize the module imports feature. Please see:
>> https://bugs.openjdk.org/browse/JDK-8344700
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'master' into JDK-8344708
>  - Adjusting ToolProviderTest to the updated persistence handling.
>  - Merge branch 'master' into JDK-8344708
>  - Reflecting review feedback: cleanup formatting in ModuleInfo.
>  - Reflecting review feedback - avoiding hardcoded constants.
>  - Fixing test.
>  - Cleanup, fixing tests.
>  - Adjusting JShell defaults.
>  - Fixing tests.
>  - Cleanup - updated specification will permit requires transitive java.base; for all classfile versions; java.se no longer participates in preview.
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/1f228e55...da39d0ef

lgtm

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23801#pullrequestreview-2799330111

From dfuchs at openjdk.org  Mon Apr 28 13:40:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 28 Apr 2025 13:40:53 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v8]
In-Reply-To: <1s3MwTXb7v_7WWORxAL4WXOlbMOnpCkt8kbjc613-UM=.a81c62cc-4cc5-4714-8d3b-a63f0b9e092d@github.com>
References: 
 <1s3MwTXb7v_7WWORxAL4WXOlbMOnpCkt8kbjc613-UM=.a81c62cc-4cc5-4714-8d3b-a63f0b9e092d@github.com>
Message-ID: <4Rrs1AMrJ4M-_7x6li7dDhSVnasUVy8w4I42IjZCU30=.f0c85e6b-3bb8-464e-a006-3a34e77e06c9@github.com>

On Sat, 26 Apr 2025 17:07:33 GMT, Markus KARG  wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.'

src/java.base/share/classes/java/lang/StringBuilder.java line 2:

> 1: /*
> 2:  * Copyright (c) 2003, 2025, Oracle and/or its affiliates. All rights reserved.

If there's no change to this file the copyright year update could be reverted?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2063662687

From jvernee at openjdk.org  Mon Apr 28 13:43:52 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 28 Apr 2025 13:43:52 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v2]
In-Reply-To: 
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 
Message-ID: 

On Fri, 18 Apr 2025 18:25:54 GMT, Chen Liang  wrote:

>> Perf numbers for simple main:
>> Linking of `Class::forName0` down from ~152 to ~83
>> 
>> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
>> JNI: ~45
>> baseline panama: ~164
>> patch: ~103
>> 
>> Also see #24705.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify FFM linker warmup

make/jdk/src/classes/build/tools/classlist/HelloClasslist.java line 184:

> 182:                 ADDRESS, ADDRESS, ADDRESS,
> 183:                 JAVA_BOOLEAN, ADDRESS, ADDRESS);
> 184:         Linker.nativeLinker().downcallHandle(signature);

Why do we care specifically about this shape, but not about others?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2063684813

From liach at openjdk.org  Mon Apr 28 13:52:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 13:52:51 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v2]
In-Reply-To: 
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 
 
Message-ID: 

On Mon, 28 Apr 2025 13:40:47 GMT, Jorn Vernee  wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify FFM linker warmup
>
> make/jdk/src/classes/build/tools/classlist/HelloClasslist.java line 184:
> 
>> 182:                 ADDRESS, ADDRESS, ADDRESS,
>> 183:                 JAVA_BOOLEAN, ADDRESS, ADDRESS);
>> 184:         Linker.nativeLinker().downcallHandle(signature);
> 
> Why do we care specifically about this shape, but not about others?

That was from the past attempt of linking Class forName0. Tge exact shape doesn't really matter here as we are mainly saving on DMH.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2063704198

From jpai at openjdk.org  Mon Apr 28 13:53:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Apr 2025 13:53:48 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v8]
In-Reply-To: <-URvYrp9EyFasdRQatbyCU2qAo5UpnOXiXliBfNzTa4=.e2651b6e-6d61-40a4-aaa4-6c57f5a32a4b@github.com>
References: 
 <-URvYrp9EyFasdRQatbyCU2qAo5UpnOXiXliBfNzTa4=.e2651b6e-6d61-40a4-aaa4-6c57f5a32a4b@github.com>
Message-ID: 

On Mon, 28 Apr 2025 04:12:03 GMT, Chen Liang  wrote:

>> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
>> 
>> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
>> 
>> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
>> 
>> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test updates - remove repetition, test case for no stale installation

Hello Chen, my experience with ClassValue is non-existent. I'll however review this in the coming days and take a look at that class and the discussions here and other places. If in the meatime you do receive an approval of these changes, then please do go ahead without waiting for mine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24043#issuecomment-2835320393

From jvernee at openjdk.org  Mon Apr 28 13:55:28 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 28 Apr 2025 13:55:28 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33]
In-Reply-To: 
References: 
 
 
 <3arhaBIc5A-NbGpFZ_ehEMQhTzXSeIlel9cFNWwg9gE=.a1f457a0-ed07-4016-82ea-bace156ff4e9@github.com>
 
 
 
 
Message-ID: 

On Mon, 28 Apr 2025 11:29:46 GMT, Maurizio Cimadamore  wrote:

>> Yeah, that was what I was thinking too.
>
> Note - the JEP uses the word `content` (which has, I think, been "vetted"). So I believe it would be ok (and, preferrable) to leave it as is. Unless you are suggesting to also update the JEP?

I've been told by several native speakers that both "content" and "contents" work, but the latter is preferable. My personal view is that "contents" feels more natural. I think if it's updated here in the javadoc, then updating the JEP would also be a logical conclusion.

However, if the decision to use "content" comes from the JEP, then I'd say stick with that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2063708103

From liach at openjdk.org  Mon Apr 28 14:02:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 14:02:51 GMT
Subject: RFR: 8341275: Explicit counter support for Code attribute building
 [v2]
In-Reply-To: <0QEX0NA3qOGsRadwDcp42BhyOeZl09677eskI00x7Lo=.bd667709-7c30-4489-8013-411326e63813@github.com>
References: 
 <0QEX0NA3qOGsRadwDcp42BhyOeZl09677eskI00x7Lo=.bd667709-7c30-4489-8013-411326e63813@github.com>
Message-ID: 

On Sun, 27 Apr 2025 03:38:35 GMT, Chen Liang  wrote:

>> Internal explicit counter support for Code max_stack and max_locals has been already added in #24807. Since that example works well, we may consider opening this functionality up to general users under strict restrictions.
>> 
>> This is an advanced API; thus, I chose a more complex name `withExplicitStackAndLocals` that discourages accidental use, and indicates the exact order of stack and locals arguments. For integrity, the argument checks are unconditional. And this is also barred behind `DROP_STACK_MAPS` advanced option.
>> 
>> I have enhanced the tests with a `CodeBuilderType` utility to test all types of code builders; it is already effective at increasing coverage in some of our existing tests that only cover DirectCodeBuilder, and simplify other tests. It is particularly helpful for my new `BuilderExplicitMaxsTest`.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust indents

I think the original issue was created in response to a public request https://mail.openjdk.org/pipermail/classfile-api-dev/2024-August/000545.html. It just happens that we and another public audience both want this API, so I guess it is not too much of a "corner case"?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24903#issuecomment-2835350966

From epeter at openjdk.org  Mon Apr 28 14:09:59 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 28 Apr 2025 14:09:59 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 25 Apr 2025 07:24:15 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 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:
> 
>  - Addressed some review comments
>    
>    1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
>    2. Improve code comments.
>  - Merge branch 'master' into JDK-8354242
>  - Merge branch 'master' into JDK-8354242
>  - 8354242: VectorAPI: combine vector not operation with compare
>    
>    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	2...

test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java line 237:

> 235:     public static void testCompareEQMaskNotByte() {
> 236:         testCompareMaskNotByte(VectorOperators.EQ);
> 237:     }

Another comment: you now only have "negative" tests, where you check for count `=0`. It would be good if you also had a positive rule here, one where you do see an XOR in a similar case, where your optimization does apply.

This would basically be a "control" that checks that your are testing the right thing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2063741513

From rgiulietti at openjdk.org  Mon Apr 28 14:10:50 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 28 Apr 2025 14:10:50 GMT
Subject: RFR: 4837946: Faster multiplication and exponentiation of large
 integers [v19]
In-Reply-To: 
References: 
 
 
 
 <8Cd065O2M59QfLt9yaOtn61ZEfB3V-oy1ppTn1Ho-pQ=.6d9ee1ab-bdf4-4619-aacf-68d7927635fd@github.com>
 
Message-ID: 

On Thu, 24 Apr 2025 20:18:42 GMT, fabioromano1  wrote:

>> @fabioromano1 I just had a cursory glance at this PR.
>> 
>> AFAIU, there are two main contributions here:
>> 
>> - Performance enhancements in `pow()`, which is of general interest and does not require submitting a [CSR](https://wiki.openjdk.org/display/csr/Main).
>> - Introduction of a new public API point for the _n_-th root, which would require a CSR.
>> 
>> It's important to understand that if we add public API points, there must be some evidence and consensus about their general usefulness and demand for them. Every addition is a commitment for this community in terms of code maintenance, reviews, testing, documentation, so they should be evaluated with this perspective in mind.
>> 
>> In this case, I feel that the proposed _n_-th root might not be among the top priority API points to add to `BigInteger`. Perhaps the overall plan is to use this method to implement a _n_-th root in `BigDecimal` in some followup PR, but this is not stated here.
>> 
>> Anyway, a [preliminary discussion](https://openjdk.org/guide/#socialize-your-change) about the proposal should take place on the mailing list, _before_ submitting the PR and invest too much work on the code.
>> 
>> To make progress here, I suggest to split this PR in two, if technically possible:
>> 
>> - One for the enhancements in `pow`, with JMH results before/after.
>> - Another PR for the proposed _n_-th root.
>> 
>> Thanks
>
>> * Performance enhancements in `pow()`, which is of general interest and does not require submitting a [CSR](https://wiki.openjdk.org/display/csr/Main).
> 
> @rgiulietti Yes, but here, the primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
> 
>> To make progress here, I suggest to split this PR in two, if technically possible:
>> 
>> * One for the enhancements in `pow`, with JMH results before/after.
>> * Another PR for the proposed _n_-th root.
> 
> I'm not very sure if it is technically possible, because both `pow()` and `nthRoot()` requires the computation of a power of a long, so that code has to be shared by both methods, and so a supposed PR for `nthRoot()` would require that method.

@fabioromano1 What's going on here? I guess this splits the original PR in two parts, as suggested?
It would be better to discuss such matters before submitting a PR.

I created a new JBS issue to refer to.
https://bugs.openjdk.org/browse/JDK-8355719
Let me know if the new title and the description convey the gist of the PR.

The current JBS issue is about speed improvements in multiplication and exponentiation, and is closed as Resolved since more than 10 years.
Please adjust the PR accordingly, by changing the title.

Also, your claims about memory consumption reduction should be supported by evidence using [JMH](https://github.com/openjdk/jmh/) benchmarks.
See [this sample](https://github.com/openjdk/jmh/blob/master/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_35_Profilers.java) for how to measure memory allocation rates.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2835377026

From liach at openjdk.org  Mon Apr 28 14:11:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 14:11:57 GMT
Subject: RFR: 8355658: Allow transforms to run on elements generated by a
 builder
In-Reply-To: 
References: 
Message-ID: <5KBmWMbdcGcEVuxWl3cEOncRU8n9qvps5jCox9SJQWE=.d00e6f1a-b764-44d4-b2ca-72b01ed99362@github.com>

On Mon, 28 Apr 2025 01:43:32 GMT, Chen Liang  wrote:

> Transforms can run on a stream of class file elements. Currently, that stream can only be from a CompoundElement. We can allow a ClassFileBuilder to provide such a stream too; a recent request https://mail.openjdk.org/pipermail/classfile-api-dev/2025-April/000698.html asks for this as well.
> 
> With this patch, we can now emulate this ASM pattern easily:
> 
> 
> // ASM
> ClassVisitor cv = new DelegateClassVisitor(new ClassWriter(...));
> cv.visitXxx(); // write elements through the delegate
> 
> // ClassFile API
> cf.build(..., clb0 -> clb0.transforming((clb, cle) -> /*process */, clb -> {
>     // write elements through delegate
> }));
> 
> 
> Notably, this patch introduces a source incompatibility (but not binary) in order to allow users to call `transform(model, (xb, xe) -> {})` or `transforming((xb1, xe) -> {}, xb1 -> {})`. This has little impact if users don't use `ClassFileBuilder` as a type directly (which according to grep.app, there are only two sites on whole GitHub, both updated in this PR). A release note has been created for this incompatibility at https://bugs.openjdk.org/browse/JDK-8355665; please review too.

Indeed, even if we want to construct a transformed handler, an instance method on `ClassFileTransform` is better.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24908#issuecomment-2835381183

From liach at openjdk.org  Mon Apr 28 14:11:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 14:11:58 GMT
Subject: Withdrawn: 8355658: Allow transforms to run on elements generated by a
 builder
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Apr 2025 01:43:32 GMT, Chen Liang  wrote:

> Transforms can run on a stream of class file elements. Currently, that stream can only be from a CompoundElement. We can allow a ClassFileBuilder to provide such a stream too; a recent request https://mail.openjdk.org/pipermail/classfile-api-dev/2025-April/000698.html asks for this as well.
> 
> With this patch, we can now emulate this ASM pattern easily:
> 
> 
> // ASM
> ClassVisitor cv = new DelegateClassVisitor(new ClassWriter(...));
> cv.visitXxx(); // write elements through the delegate
> 
> // ClassFile API
> cf.build(..., clb0 -> clb0.transforming((clb, cle) -> /*process */, clb -> {
>     // write elements through delegate
> }));
> 
> 
> Notably, this patch introduces a source incompatibility (but not binary) in order to allow users to call `transform(model, (xb, xe) -> {})` or `transforming((xb1, xe) -> {}, xb1 -> {})`. This has little impact if users don't use `ClassFileBuilder` as a type directly (which according to grep.app, there are only two sites on whole GitHub, both updated in this PR). A release note has been created for this incompatibility at https://bugs.openjdk.org/browse/JDK-8355665; please review too.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24908

From liach at openjdk.org  Mon Apr 28 14:14:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 14:14:53 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v38]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 28 Apr 2025 07:29:10 GMT, fabioromano1  wrote:

>> src/java.base/share/classes/java/math/BigInteger.java line 2746:
>> 
>>> 2744:             if (exp <= maxExp) {
>>> 2745:                 // don't use fp arithmetic if exp <= 3
>>> 2746:                 xToExp = exp == 1 ? x :
>> 
>> What about pre-seeding the cache with values for 1, 2 and 3? That would allow unconditionally using fp here (and below)
>
>> What about pre-seeding the cache with values for 1, 2 and 3? That would allow unconditionally using fp here (and below)
> 
> It's a good idea, but doing so would increase the already high dependence of `computePower()` by the preconditions given by `unsignedLongPow()`, so at this point I wonder if it will still make sense to maintain the code separated, rather than putting it in `unsignedLongPow()` and throw away `computePower()`...

Doesn't pre-seeding involve extra cpu cycles which are defintely wasted if the results aren't used?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2063752957

From epeter at openjdk.org  Mon Apr 28 14:16:53 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 28 Apr 2025 14:16:53 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v3]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: <41Y44tSReVYSBYslzzcs-GGyQ6SPM2CfTkJ3-MpGBYM=.cbb47073-5d30-4391-9d67-b2fa758f4dca@github.com>

On Mon, 28 Apr 2025 09:51:10 GMT, erifan  wrote:

> > > > Just a drive-by comment for now, I may review this later more fully.
> > > > > I would also prefer if you added the IR restrictions rather than the JTREG requires.
> > > > > The benefit is that we can still run the tests on all platforms, at least for result verification.
> > > > > Imagine someone adds optimizations to a new platform, but does not know about this test here. They make a mistake, and there is a bug, leading either to a crash or wrong result. With the requires, you test would never even run, and we would not catch it. With the IR applyIf, we would catch the bug.
> > > > 
> > > > 
> > > > Just copy pasting the IR applyIf everywhere is not that much work, and adding in a new platform later is not really hard either.
> > > 
> > > 
> > > Thanks! The problem is that when a new platform is added, people may not even know there is a test.
> > 
> > 
> > @erifan That is true. But we have that problem either way. If you use `@require`, then the person does not realize there is a test AND the test is not run. If you use `applyIf`, the person does not realize there is a test, but it is run at least for result verifiation - and then the person MIGHT realize if the test catches a wrong result / crash.
> 
> This test will run on new platforms when we use @requires. I explained the meaning of the @requires in the previous comment, it only excludes one case: when -XX:UseAVX=0 is specified on x86 platforms.

I see. You should probably add a comment there, to say that you are only excluding `AVX=0`.
But even `UseAVX = 0` would profit from result verification.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-2835397926

From epeter at openjdk.org  Mon Apr 28 14:16:53 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 28 Apr 2025 14:16:53 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v2]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
Message-ID: 

On Mon, 28 Apr 2025 07:46:14 GMT, erifan  wrote:

>> I would also prefer if you added the IR restrictions rather than the JTREG requires.
>> The benefit is that we can still run the tests on all platforms, at least for result verification.
>> 
>> Imagine someone adds optimizations to a new platform, but does not know about this test here. They make a mistake, and there is a bug, leading either to a crash or wrong result. With the requires, you test would never even run, and we would not catch it. With the IR applyIf, we would catch the bug.
>
> I can make the change, it's not complex, but it is different from what I thought before.
> 
> I thought that supporting vector was the default behavior, is it right? So when I was doing an architecture-independent feature or optimization, I should just exclude those unsupported cases from the test, so that all potential environments would be tested. If I was doing an architecture- or feature-dependent optimization, then I should limit the test to run only in supported environments.
> 
> For this case, **the current meaning of @requires is "skip this test when -XX:UseAVX=0 is specified on the x86 architecture, otherwise run the tests".** So if a new architecture (say s390) supports related vector operations in the future, then this test will be run on that platform by default.
> 
> If all architecture-independent tests are restricted with applyIfCPUFeatureOr, then when we support a new architecture, we will need to modify all tests, otherwise no test will run on this architecture.

Hmm, I'm not convinced that vector operations are supported by default. Every platform supports a different set.

In your case, you so far only have negative rules, i.e. you expect certain nodes NOT to be generated / in the final IR. I suppose in that case you can assert that you NEVER get those nodes, because if you have vectors not supported, they will not show up because of that, and if you do support vectors, they should be optimized away.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2063752141

From epeter at openjdk.org  Mon Apr 28 14:16:56 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 28 Apr 2025 14:16:56 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 28 Apr 2025 14:06:49 GMT, Emanuel Peter  wrote:

>> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Addressed some review comments
>>    
>>    1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
>>    2. Improve code comments.
>>  - Merge branch 'master' into JDK-8354242
>>  - Merge branch 'master' into JDK-8354242
>>  - 8354242: VectorAPI: combine vector not operation with compare
>>    
>>    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...
>
> test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java line 237:
> 
>> 235:     public static void testCompareEQMaskNotByte() {
>> 236:         testCompareMaskNotByte(VectorOperators.EQ);
>> 237:     }
> 
> Another comment: you now only have "negative" tests, where you check for count `=0`. It would be good if you also had a positive rule here, one where you do see an XOR in a similar case, where your optimization does apply.
> 
> This would basically be a "control" that checks that your are testing the right thing.

Also: this test should vectorize on some plarforms, right? A compare, correct? Would it not be good to actively check that with an IR rule?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2063749337

From duke at openjdk.org  Mon Apr 28 14:20:48 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 28 Apr 2025 14:20:48 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v38]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Mon, 28 Apr 2025 14:12:29 GMT, Chen Liang  wrote:

> Doesn't pre-seeding involve extra cpu cycles which are defintely wasted if the results aren't used?

It would involve just 3 assignments and 3 multiplications of 64-bit words, I think the overhead is negligible.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2063765833

From liach at openjdk.org  Mon Apr 28 14:26:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 14:26:46 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v2]
In-Reply-To: 
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 
 
 
Message-ID: <_bX7wPu7a39ujK5Wi-iS0IvVEfDHG438lCaNRXhT_R8=.fbad2ac1-97a1-417b-a080-f360f38dc66b@github.com>

On Mon, 28 Apr 2025 13:50:17 GMT, Chen Liang  wrote:

>> make/jdk/src/classes/build/tools/classlist/HelloClasslist.java line 184:
>> 
>>> 182:                 ADDRESS, ADDRESS, ADDRESS,
>>> 183:                 JAVA_BOOLEAN, ADDRESS, ADDRESS);
>>> 184:         Linker.nativeLinker().downcallHandle(signature);
>> 
>> Why do we care specifically about this shape, but not about others?
>
> That was from the past attempt of linking Class forName0. Tge exact shape doesn't really matter here as we are mainly saving on DMH.

Can I just change this signature to `FunctionDescriptor.ofVoid()`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2063776900

From liach at openjdk.org  Mon Apr 28 14:29:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 14:29:56 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v38]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Mon, 28 Apr 2025 14:18:34 GMT, fabioromano1  wrote:

>> Doesn't pre-seeding involve extra cpu cycles which are defintely wasted if the results aren't used?
>
>> Doesn't pre-seeding involve extra cpu cycles which are defintely wasted if the results aren't used?
> 
> It would involve just 3 assignments and 3 multiplications of 64-bit words, I think the overhead is negligible.

In this case you can still use computePower and remove the branching to check if double arithmetic should be used - you are passing the cache array, so you can control what is the initial values in that array.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2063782835

From duke at openjdk.org  Mon Apr 28 14:33:55 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 28 Apr 2025 14:33:55 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v38]
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: 

On Mon, 28 Apr 2025 14:27:00 GMT, Chen Liang  wrote:

> In this case you can still use computePower and remove the branching to check if double arithmetic should be used - you are passing the cache array, so you can control what is the initial values in that array.

Yes, but if I have to check the contents of the cache, then it's useless to remove the branching to check if double arithmetic should be used, since the same check has to be done previously.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2063790215

From liach at openjdk.org  Mon Apr 28 14:36:33 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 14:36:33 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v3]
In-Reply-To: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
Message-ID: 

> Perf numbers for simple main:
> Linking of `Class::forName0` down from ~152 to ~83
> 
> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
> JNI: ~45
> baseline panama: ~164
> patch: ~103
> 
> Also see #24705.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
 - Use more simple function descriptor
 - Simplify FFM linker warmup
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
 - Wip work trying to speed up FFM

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24742/files
  - new: https://git.openjdk.org/jdk/pull/24742/files/dbf7799c..f762f72f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24742&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24742&range=01-02

  Stats: 46599 lines in 1266 files changed: 35620 ins; 7149 del; 3830 mod
  Patch: https://git.openjdk.org/jdk/pull/24742.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24742/head:pull/24742

PR: https://git.openjdk.org/jdk/pull/24742

From alanb at openjdk.org  Mon Apr 28 14:57:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Apr 2025 14:57:49 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 25 Apr 2025 14:26:43 GMT, Michael McMahon  wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - update to minimise code changes
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Apply suggestions from code review
>    
>    from turbanoff review
>    
>    Co-authored-by: Andrey Turbanov 
>  - doc + copyright update
>  - remove file added by mistake
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/5c067232...9401d4c8

src/java.base/share/conf/security/java.security line 1311:

> 1309: #  hostInfo - Special value which signifies the three categories above combined
> 1310: #             (socket, addressLookup, net). This is provided for compatibility
> 1311: #             with previous releases.

Are you sure "socket", "addressLookup", and "net" categories are useful and needed? I would think someone configuring this is looking to keeping sensitive fields out of the exception messages without knowing exactly which APIs are used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2063849188

From duke at openjdk.org  Mon Apr 28 15:08:03 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 28 Apr 2025 15:08:03 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v39]
In-Reply-To: 
References: 
Message-ID: <38QcTDWOMXZcn8uFx32Sc_gSbYeTe1x2tq4pdZrTxLY=.80624c27-719e-4150-97ab-047f1b62c345@github.com>

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Pre-cache the powers of x up to x^3 to simplify the code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/fcd5d550..b831d017

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=38
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=37-38

  Stats: 11 lines in 1 file changed: 3 ins; 6 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From duke at openjdk.org  Mon Apr 28 15:28:58 2025
From: duke at openjdk.org (kabutz)
Date: Mon, 28 Apr 2025 15:28:58 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
Message-ID: 

We logged several bugs on the LinkedBlockingDeque. This aggregates them into a single bug report and PR.

1. LinkedBlockingDeque does not immediately throw InterruptedException in put/take

The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down.

2. LinkedBlockingDeque.clear() should preserve weakly-consistent iterators

LinkedBlockingDeque.clear() should preserve weakly-consistent iterators by linking f.prev and f.next back to f, allowing the iterators to continue from the first or last respectively. This would be consistent with how the other node-based weakly consistent queues LinkedBlockingQueue LinkedTransferQueue, ConcurrentLinkedQueue/Deque work.

The LBD already supports self-linking, since that is done by the unlinkFirst() and unlinkLast() methods, and the iterators and spliterator thus all support self-linking.

This can be fixed very easily by linking both f.prev and f.next back to f.

3. LinkedBlockingDeque offer() creates nodes even if capacity has been reached

In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking.

In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field.

4. LinkedBlockingDeque allows us to overflow size with addAll()

In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then add that chain in bulk to the existing nodes. We count the nodes in "int n" and then whilst holding the lock, we check that we haven't exceeded the capacity with "if (count + n <= capacity)". However, if we pass in a collection that has more than Integer.MAX_VALUE items in it, then we can overflow n, making it negative. Since "count + n" is also negative, we can add the chain to our last item, and thus we end up with a LinkedBlockingDeque with more than Integer.MAX_VALUE of items and a negative size(). stream().count() gives the correct number of items.

This happens both via the bulk add constructor LinkedBlockingDeque(Collection) and when we call addAll(Collection) directly.

-------------

Commit messages:
 - JDK-8354138: LinkedBlockingDeque allows us to overflow size with addAll()
 - JDK-8354060: LinkedBlockingDeque.clear() should preserve weakly-consistent iterators
 - JDK-8349543: LinkedBlockingDeque does not immediately throw InterruptedException in put/take
 - JDK-8354076: LinkedBlockingDeque offer() creates nodes even if capacity has been reached

Changes: https://git.openjdk.org/jdk/pull/24925/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24925&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355726
  Stats: 132 lines in 2 files changed: 95 ins; 16 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/24925.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24925/head:pull/24925

PR: https://git.openjdk.org/jdk/pull/24925

From duke at openjdk.org  Mon Apr 28 15:36:45 2025
From: duke at openjdk.org (kabutz)
Date: Mon, 28 Apr 2025 15:36:45 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: 
References: 
Message-ID: <-uuhMy2nvaxxNiV1XvPA4xRLBcG5_nxPfrFAOgWkCuw=.d8cfce6d-4574-4523-8745-3c0c00fc03a3@github.com>

On Mon, 28 Apr 2025 15:23:18 GMT, kabutz  wrote:

> We logged several bugs on the LinkedBlockingDeque. This aggregates them into a single bug report and PR.
> 
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in put/take
> 
> The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down.
> 
> 2. LinkedBlockingDeque.clear() should preserve weakly-consistent iterators
> 
> LinkedBlockingDeque.clear() should preserve weakly-consistent iterators by linking f.prev and f.next back to f, allowing the iterators to continue from the first or last respectively. This would be consistent with how the other node-based weakly consistent queues LinkedBlockingQueue LinkedTransferQueue, ConcurrentLinkedQueue/Deque work.
> 
> The LBD already supports self-linking, since that is done by the unlinkFirst() and unlinkLast() methods, and the iterators and spliterator thus all support self-linking.
> 
> This can be fixed very easily by linking both f.prev and f.next back to f.
> 
> 3. LinkedBlockingDeque offer() creates nodes even if capacity has been reached
> 
> In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking.
> 
> In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field.
> 
> 4. LinkedBlockingDeque allows us to overflow size with addAll()
> 
> In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then add that chain in bulk to the existing nodes. We count the nodes in "int n" and then whilst holding the lock, we check that we haven't exceed...

@viktorklang-ora @DougLea @AlanBateman

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24925#issuecomment-2835656740

From alanb at openjdk.org  Mon Apr 28 15:45:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Apr 2025 15:45:05 GMT
Subject: RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth
 Preview) [v10]
In-Reply-To: 
References: 
Message-ID: 

> Changes for [JEP 505: Structured Concurrency (Fifth Preview)](https://openjdk.org/jeps/8340343). The proposal is to re-preview the API with some changes, specifically:
> 
> - A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor.  Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close.
> - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner.
> - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions.
> - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function.
> - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method.
>  
> The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations.

Alan Bateman 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 JDK-8342486
 - Merge branch 'master' into JDK-8342486
 - Sync up from loom repo
 - Merge branch 'master' into JDK-8342486
 - Add JEP number, update copyright headers
 - Merge branch 'master' into JDK-8342486
 - Sync up from loom repo
 - Merge branch 'master' into JDK-8342486
 - Sync up from loom repo
 - Merge branch 'master' into JDK-8342486
 - ... and 9 more: https://git.openjdk.org/jdk/compare/21b0f5ea...de6e1e16

-------------

Changes: https://git.openjdk.org/jdk/pull/21934/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21934&range=09
  Stats: 4039 lines in 14 files changed: 1821 ins; 1438 del; 780 mod
  Patch: https://git.openjdk.org/jdk/pull/21934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21934/head:pull/21934

PR: https://git.openjdk.org/jdk/pull/21934

From duke at openjdk.org  Mon Apr 28 15:57:22 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Mon, 28 Apr 2025 15:57:22 GMT
Subject: RFR: 8354475: TestDockerMemoryMetricsSubgroup.java fails with
 exitValue = 1
Message-ID: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com>

8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1

-------------

Commit messages:
 - 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1

Changes: https://git.openjdk.org/jdk/pull/24930/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24930&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354475
  Stats: 18 lines in 1 file changed: 17 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24930.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24930/head:pull/24930

PR: https://git.openjdk.org/jdk/pull/24930

From duke at openjdk.org  Mon Apr 28 15:57:22 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Mon, 28 Apr 2025 15:57:22 GMT
Subject: RFR: 8354475: TestDockerMemoryMetricsSubgroup.java fails with
 exitValue = 1
In-Reply-To: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com>
References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com>
Message-ID: 

On Mon, 28 Apr 2025 15:51:44 GMT, PAWAN CHAWDHARY  wrote:

> 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1

TestDockerMemoryMetricsSubgroup.java creates directory under /sys/fs/cgroup by running following command for this test needs to be run as root mode
`mkdir -p /sys/fs/cgroup/memory/test`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24930#issuecomment-2835722446

From viktor.klang at oracle.com  Mon Apr 28 15:58:53 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 28 Apr 2025 15:58:53 +0000
Subject: [External] : Re: Casting gatherer
In-Reply-To: 
References: 
 
 
Message-ID: 

In this case, it is rather straight-forward to experiment?given Gatherers?and be able to make progress on ergonomics without waiting for the standard library to offer a built-in.


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Nir Lisker 
Sent: Monday, 28 April 2025 13:21
To: Viktor Klang 
Cc: core-libs-dev at openjdk.org 
Subject: [External] : Re: Casting gatherer

Hi Viktor,

stream.filter(myClass:isInstance).map(myClass:cast)

is indeed the current way of doing it. I've written this code many times and I suspect others have too. An extracted version might reside in many utility classes. This is why I suggested having a Gatherer for it in Gatherers. I've written a naive implementation:

private static  Gatherer filterCast(Class type) {
    return Gatherer.of(
        (_, element, downstream) -> {
            if (type.isInstance(element)) {
                return downstream.push(type.cast(element));
            }
            return true;
        }
    );
}

which we might start seeing in gatherer libraries.

We don't need to be able to write 'x instanceof T', although it would be useful in many cases. It's a discussion for Valhalla. Valhalla will also allow us to use this for "non-class based" elements when generics over primitives arrive, so this gatherer is no different than the others.

As noted above, Amber might offer solutions too. Obviously, lower-level solutions from Valhalla and Amber are preferable, but I don't know what the plans are. Maybe you can discuss this internally. Otherwise, do you think this is a good fit?

-- Nir

On Mon, Apr 28, 2025 at 12:02?PM Viktor Klang > wrote:
The challenge here is that there is no, current, reification of a pattern application, so all it boils down to at this point is: given a Predicate for some type T, make a cast to some unrelated type R.

For Class-based retention of elements, it is possible to do the equivalent of testing Class::isInstance(element) and then push the element downstream after a Class::cast(element)

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev > on behalf of Nir Lisker >
Sent: Saturday, 26 April 2025 20:55
To: core-libs-dev at openjdk.org >
Subject: Casting gatherer

Hi,

instanceof has been refitted to include an auto-cast ("pattern matching on instanceof"). Unfortunately, doing this as an intermediate operation on a stream requires first to filter via instanceof and then map via a cast. This is because

    x instanceof MyClass myClass

returns a boolean, not myClass.

I've asked for an easier way of doing it long ago directly on Stream and was declined, but now with Gatherers I'm bringing this up again. I think it would be reasonable to put such an operation in the Gatherers class. I imagine that many Gatherer libraries, or utility classes, will include it since it's a common operation, and having it in the JDK means that it'll be done the best way possible (you can optimize where others can't, if applicable here).

-- Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vklang at openjdk.org  Mon Apr 28 16:06:47 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 28 Apr 2025 16:06:47 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v2]
In-Reply-To: 
References: 
 <9yknKYCR2xdWz_WAU7ZLbrS7KNYhq4E-FhqiKBylu5o=.159e2fb5-4fb8-4535-88c5-03412f7df988@github.com>
 
 
Message-ID: <5FxbMvjOY-2dzyQuu1HwBT-6aFQwWhDZ74HKC3Foxuo=.65bff828-f956-435f-8fff-6c7a4fcf7166@github.com>

On Mon, 28 Apr 2025 04:29:40 GMT, Chen Liang  wrote:

>> Hello Chen, not a review of the code, but the tier1 failures in the GitHub actions jobs look related:
>> 
>> 
>> java.lang.StackOverflowError: Recursive initialization of class value
>> 	at java.base/java.lang.ClassValue$Entry.registerExtraThread(ClassValue.java:321)
>> 	at java.base/java.lang.ClassValue$ClassValueMap.startEntry(ClassValue.java:481)
>> 	at java.base/java.lang.ClassValue.getFromHashMap(ClassValue.java:196)
>> 	at java.base/java.lang.ClassValue.getFromBackup(ClassValue.java:183)
>> 	at java.base/java.lang.ClassValue.get(ClassValue.java:119)
>
> @jaikiran Since you have looked at this patch and used CountDownLatch frequently before, I wonder if you would like to review the use of concurrency utilities in this patch.

@liach I'll have a look as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24043#issuecomment-2835753236

From naoto at openjdk.org  Mon Apr 28 16:06:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 28 Apr 2025 16:06:51 GMT
Subject: RFR: 8355558: SJIS.java test is always ignored [v2]
In-Reply-To: 
References: 
 
Message-ID: <4OlPm5ekgvUSlhdwjV2zZvfgREHRF_ideWbtH900UYw=.9bc6b23d-37e6-4179-a02e-c9a43ddf935f@github.com>

On Fri, 25 Apr 2025 19:41:54 GMT, Naoto Sato  wrote:

>> Stemmed from this PR: https://github.com/openjdk/jdk/pull/24838
>> After JEP 400, `file.encoding` is always UTF-8, so the test was never run. Using `native.encoding` is appropriate so that the intention of the initial test will hold. Tested on an English Windows in which the system locale is set to `Japanese(Japan)`, and confirmed it succeeded without SkippedException.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Expand wild card imports

Thank you for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24881#issuecomment-2835748169

From naoto at openjdk.org  Mon Apr 28 16:06:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 28 Apr 2025 16:06:52 GMT
Subject: Integrated: 8355558: SJIS.java test is always ignored
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Apr 2025 17:02:30 GMT, Naoto Sato  wrote:

> Stemmed from this PR: https://github.com/openjdk/jdk/pull/24838
> After JEP 400, `file.encoding` is always UTF-8, so the test was never run. Using `native.encoding` is appropriate so that the intention of the initial test will hold. Tested on an English Windows in which the system locale is set to `Japanese(Japan)`, and confirmed it succeeded without SkippedException.

This pull request has now been integrated.

Changeset: c0dc3142
Author:    Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/c0dc31422d6e7435ad7abdb547dedcc50b7fc0c3
Stats:     13 lines in 1 file changed: 9 ins; 0 del; 4 mod

8355558: SJIS.java test is always ignored

Reviewed-by: bpb

-------------

PR: https://git.openjdk.org/jdk/pull/24881

From bpb at openjdk.org  Mon Apr 28 16:10:45 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 28 Apr 2025 16:10:45 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value
In-Reply-To: 
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
 
Message-ID: 

On Fri, 25 Apr 2025 10:25:02 GMT, Mark Sheppard  wrote:

> test/jdk/java/io/File/MacPathTest.java test/jdk/java/io/File/MaxPath.java
> 
> maybe for these two cases, throw a SkippedException rather than just return ?

`MacPathTest` is run by `MacPath` in a `ProcessBuilder` so there is really no change for that one from the current master after the most recent commit (5d24645).

`MaxPath` could throw a `SkippedException` instead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24860#issuecomment-2835767241

From jpai at openjdk.org  Mon Apr 28 16:21:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Apr 2025 16:21:50 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value [v2]
In-Reply-To: 
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
 
Message-ID: 

On Fri, 25 Apr 2025 16:50:42 GMT, Brian Burkhalter  wrote:

>> Use the `@requires` tag instead of obtaining the operating system name from the `os.name` property and then exiting if the test is not run on that operating system.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8355444: Revert addition of @requires to MacPathTest and add a comment

The updated changes look good to me. Thank you Brian.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24860#pullrequestreview-2799924044

From jpai at openjdk.org  Mon Apr 28 16:25:46 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Apr 2025 16:25:46 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value [v2]
In-Reply-To: 
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
 
Message-ID: 

On Fri, 25 Apr 2025 16:50:42 GMT, Brian Burkhalter  wrote:

>> Use the `@requires` tag instead of obtaining the operating system name from the `os.name` property and then exiting if the test is not run on that operating system.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8355444: Revert addition of @requires to MacPathTest and add a comment

test/jdk/java/io/FileOutputStream/ManyFiles.java line 42:

> 40:     public static void main(String args[]) throws Exception {
> 41:         // Vestigial comment from before @requires tag was added:
> 42:         // Linux does not yet allow opening this many files; Solaris

Nit - If you do happen to update this PR for any other reason, then maybe consider adding jtreg's `@comment` in the test definition (https://openjdk.org/jtreg/tag-spec.html#INFORMATIONAL_TAGS) just before the `@requires` line and move this existing comment there.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24860#discussion_r2064043079

From bpb at openjdk.org  Mon Apr 28 16:40:03 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 28 Apr 2025 16:40:03 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value [v3]
In-Reply-To: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
Message-ID: 

> Use the `@requires` tag instead of obtaining the operating system name from the `os.name` property and then exiting if the test is not run on that operating system.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8355444: Change MaxPath to throw SkippedException

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24860/files
  - new: https://git.openjdk.org/jdk/pull/24860/files/5d246456..1df4a06c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24860&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24860&range=01-02

  Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24860/head:pull/24860

PR: https://git.openjdk.org/jdk/pull/24860

From bpb at openjdk.org  Mon Apr 28 16:45:01 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 28 Apr 2025 16:45:01 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value [v4]
In-Reply-To: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
Message-ID: 

> Use the `@requires` tag instead of obtaining the operating system name from the `os.name` property and then exiting if the test is not run on that operating system.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8355444: Add comment tag tp ManyFiles

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24860/files
  - new: https://git.openjdk.org/jdk/pull/24860/files/1df4a06c..fb9f0c5c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24860&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24860&range=02-03

  Stats: 13 lines in 1 file changed: 6 ins; 7 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24860/head:pull/24860

PR: https://git.openjdk.org/jdk/pull/24860

From bpb at openjdk.org  Mon Apr 28 16:45:01 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 28 Apr 2025 16:45:01 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value [v2]
In-Reply-To: 
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
 
 
Message-ID: 

On Mon, 28 Apr 2025 16:23:16 GMT, Jaikiran Pai  wrote:

> then maybe consider adding jtreg's `@comment` in the test

Added in fb9f0c5.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24860#discussion_r2064072161

From duke at openjdk.org  Mon Apr 28 16:48:49 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 28 Apr 2025 16:48:49 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v40]
In-Reply-To: 
References: 
Message-ID: 

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Added tests for memory consumption

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/b831d017..51272bc6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=39
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=38-39

  Stats: 157 lines in 1 file changed: 157 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From jpai at openjdk.org  Mon Apr 28 16:48:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Apr 2025 16:48:51 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value [v4]
In-Reply-To: 
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
 
Message-ID: 

On Mon, 28 Apr 2025 16:45:01 GMT, Brian Burkhalter  wrote:

>> Use the `@requires` tag instead of obtaining the operating system name from the `os.name` property and then exiting if the test is not run on that operating system.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8355444: Add comment tag tp ManyFiles

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24860#pullrequestreview-2799995388

From duke at openjdk.org  Mon Apr 28 17:01:57 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 28 Apr 2025 17:01:57 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v19]
In-Reply-To: 
References: 
 
 
 
 <8Cd065O2M59QfLt9yaOtn61ZEfB3V-oy1ppTn1Ho-pQ=.6d9ee1ab-bdf4-4619-aacf-68d7927635fd@github.com>
 
 
Message-ID: 

On Mon, 28 Apr 2025 14:08:02 GMT, Raffaello Giulietti  wrote:

>>> * Performance enhancements in `pow()`, which is of general interest and does not require submitting a [CSR](https://wiki.openjdk.org/display/csr/Main).
>> 
>> @rgiulietti Yes, but here, the primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>> 
>>> To make progress here, I suggest to split this PR in two, if technically possible:
>>> 
>>> * One for the enhancements in `pow`, with JMH results before/after.
>>> * Another PR for the proposed _n_-th root.
>> 
>> I'm not very sure if it is technically possible, because both `pow()` and `nthRoot()` requires the computation of a power of a long, so that code has to be shared by both methods, and so a supposed PR for `nthRoot()` would require that method.
>
> @fabioromano1 What's going on here? I guess this splits the original PR in two parts, as suggested?
> It would be better to discuss such matters before submitting a PR.
> 
> I created a new JBS issue to refer to.
> https://bugs.openjdk.org/browse/JDK-8355719
> Let me know if the new title and the description convey the gist of the PR.
> 
> The current JBS issue is about speed improvements in multiplication and exponentiation, and is closed as Resolved since more than 10 years.
> Please adjust the PR accordingly, by changing the title.
> 
> Also, your claims about memory consumption reduction should be supported by evidence using [JMH](https://github.com/openjdk/jmh/) benchmarks.
> See [this sample](https://github.com/openjdk/jmh/blob/master/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_35_Profilers.java) for how to measure memory allocation rates.

@rgiulietti The title and description of the JBS issue are ok. I've added tests for comparing time and memory consumption.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2835899308

From rriggs at openjdk.org  Mon Apr 28 17:05:51 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 28 Apr 2025 17:05:51 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value [v4]
In-Reply-To: 
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
 
Message-ID: 

On Mon, 28 Apr 2025 16:45:01 GMT, Brian Burkhalter  wrote:

>> Use the `@requires` tag instead of obtaining the operating system name from the `os.name` property and then exiting if the test is not run on that operating system.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8355444: Add comment tag tp ManyFiles

There are lots of tests using @requires to only run on relevant configurations.
If there needs to be more complete accounting of tests not run on each platform, it belongs as a feature in jtreg. 
Switching to use SkippedException in some tests but not having a clear and consistent distinction seems like just making things more complicated and harder to understand on a test by test basis.
The ship may have sailed here, but a more consistent pattern should be developed.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24860#pullrequestreview-2800046182

From rgiulietti at openjdk.org  Mon Apr 28 17:09:48 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 28 Apr 2025 17:09:48 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v40]
In-Reply-To: 
References: 
 
Message-ID: <_kZNEz6jIVzlHMKNK0nPnZdVdAfI1l_X4eRrRJH62i8=.61eedea0-bb33-419d-8391-b5ae2194e6ed@github.com>

On Mon, 28 Apr 2025 16:48:49 GMT, fabioromano1  wrote:

>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added tests for memory consumption

Can you show the benchmark results before/after, perhaps specifying the characteristics of your machine (CPU make/model, RAM, OS)?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2835918506

From lancea at openjdk.org  Mon Apr 28 17:10:47 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 28 Apr 2025 17:10:47 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value [v4]
In-Reply-To: 
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
 
 
Message-ID: 

On Mon, 28 Apr 2025 17:03:10 GMT, Roger Riggs  wrote:

> There are lots of tests using @requires to only run on relevant configurations. If there needs to be more complete accounting of tests not run on each platform, it belongs as a feature in jtreg. Switching to use SkippedException in some tests but not having a clear and consistent distinction seems like just making things more complicated and harder to understand on a test by test basis. The ship may have sailed here, but a more consistent pattern should be developed.

Brian created https://bugs.openjdk.org/browse/CODETOOLS-7903996 to have the JTREG reporting improved

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24860#issuecomment-2835920957

From bpb at openjdk.org  Mon Apr 28 17:24:46 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 28 Apr 2025 17:24:46 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value [v4]
In-Reply-To: 
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
 
 
 
Message-ID: 

On Mon, 28 Apr 2025 17:08:02 GMT, Lance Andersen  wrote:

> Brian created https://bugs.openjdk.org/browse/CODETOOLS-7903996 to have the JTREG reporting improved

Yes, and this comment was added to that issue since then

"Please note the work having been done in https://bugs.openjdk.org/browse/JDK-8343832"

so it looks like this is being taken hand already.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24860#issuecomment-2835960257

From rriggs at openjdk.org  Mon Apr 28 18:24:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 28 Apr 2025 18:24:53 GMT
Subject: Integrated: 8354053: Remove unused JavaIOFilePermissionAccess
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Apr 2025 21:26:08 GMT, Roger Riggs  wrote:

> The JavaIOFilePermissionAccess interface is removed from SharedSecrets and its implementation (FilePermCompat.java) used by the test is moved to java.io FilePermission where cross package access is not needed. 
> The test FilePermissionCollectionMerge is updated to access the internal implementation in FilePermission. 
> Modernized the initialization from the system property `jdk.io.permissionsUseCanonicalPath`. 
> The remaining support will be removed when FilePermission is removed.

This pull request has now been integrated.

Changeset: 2f844803
Author:    Roger Riggs 
URL:       https://git.openjdk.org/jdk/commit/2f8448034f28276ad5ac1edfa0fb8650e47d4ffa
Stats:     260 lines in 5 files changed: 57 ins; 175 del; 28 mod

8354053: Remove unused JavaIOFilePermissionAccess

Reviewed-by: liach, weijun

-------------

PR: https://git.openjdk.org/jdk/pull/24603

From msheppar at openjdk.org  Mon Apr 28 18:47:47 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 28 Apr 2025 18:47:47 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value [v4]
In-Reply-To: 
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
 
 
 
 
Message-ID: 

On Mon, 28 Apr 2025 17:22:36 GMT, Brian Burkhalter  wrote:

> > Brian created https://bugs.openjdk.org/browse/CODETOOLS-7903996 to have the JTREG reporting improved
> 
> Yes, and this comment was added to that issue since then
> 
> "Please note the work having been done in https://bugs.openjdk.org/browse/JDK-8343832"
> 
> so it looks like this is being taken hand already.

The above  https://bugs.openjdk.org/browse/JDK-8343832 is the reporting of Skipped in jtreg summary, which is taking into account the throw SkippedException idiom

But if the general consensus is to use the @requires for selective OS execution, then greater visibility of the "not run" category of tests is required in he CI pipeline reports

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24860#issuecomment-2836172411

From jiangli at openjdk.org  Mon Apr 28 18:57:55 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 28 Apr 2025 18:57:55 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: 
References: 
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
 
 
Message-ID: 

On Mon, 28 Apr 2025 13:04:57 GMT, Jorn Vernee  wrote:

> > Having to upgrade to JNI is a bit sad -- although I get that it is required as a workaround for now. For the longer term I'd prefer a better way to integrate static lookups in the FFM API. For instance, all `JNI::loadLibrary` does when it comes to static libraries is to return the so called "process handle" -- e.g. a handle to the running process (the JVM). If there was a way to retrieve such a handle (e.g. via a dedicated `SymbolLookup` factory) it would be possible to avoid the JNI dance: just get the process symbol lookup, and look for statically linked symbols in there.
> 
> I remember this wasn't quite as elegant on Windows, but I suppose there is already some solution in place to look up symbols that are statically linked into the same executable?

With the current effort for enhancing/completing static JDK support, the system is able to detect if it's running on static using checks like `is_vm_statically_linked/JVM_IsStaticallyLinked/JLI_IsStaticallyLinked`. For example, `os::native_java_library` (https://github.com/openjdk/jdk/blob/2f8448034f28276ad5ac1edfa0fb8650e47d4ffa/src/hotspot/share/runtime/os.cpp#L516) and `load_zip_library` retrieve the `os::get_default_process_handle` without doing `dlopen` (e.g. on Linux) to load the native libraries. For longer term, we can make the solution more coherent/general for handling the various cases in the system.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2836196239

From jiangli at openjdk.org  Mon Apr 28 18:57:56 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 28 Apr 2025 18:57:56 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: 
References: 
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
 
Message-ID: 

On Mon, 28 Apr 2025 08:30:43 GMT, Maurizio Cimadamore  wrote:

>> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
>>  - Address henryjen@ comment:
>>    - Remove '#include '.
>
> The changes here look good. Essentially, if `syslookup` is statically linked, trying to do a `dlopen` on it will fail, as the shared library for it doesn't exist. For this reason, this PR seems to "upgrade" syslookup to a JNI library. The presence of the `JNI_OnLoad_syslookup` is then used, as per [JEP 178](https://openjdk.org/jeps/178) to determine whether `syslookup` is a "builtin" library -- that is, a library for which no dynamic linking should occur.
> 
> The loaded library is associated with the boot classloader. This could be problematic, in principle. However, since the requests to `loadLibrary` also come from the boot loader (they are from the `SystemLookup` class) it all works out ok.
> 
> Having to upgrade to JNI is a bit sad -- although I get that it is required as a workaround for now. For the longer term I'd prefer a better way to integrate static lookups in the FFM API. For instance, all `JNI::loadLibrary` does when it comes to static libraries is to return the so called "process handle" -- e.g. a handle to the running process (the JVM). If there was a way to retrieve such a handle (e.g. via a dedicated `SymbolLookup` factory) it would be possible to avoid the JNI dance: just get the process symbol lookup, and look for statically linked symbols in there.

@mcimadamore @JornVernee Thanks for the in-depth thoughts and reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2836201103

From jiangli at openjdk.org  Mon Apr 28 18:57:57 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 28 Apr 2025 18:57:57 GMT
Subject: Integrated: 8355080:
 java.base/jdk.internal.foreign.SystemLookup.find() doesn't work on static JDK
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Apr 2025 21:08:56 GMT, Jiangli Zhou  wrote:

> Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
> 
> `NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.
> 
> In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.

This pull request has now been integrated.

Changeset: acd93df6
Author:    Jiangli Zhou 
URL:       https://git.openjdk.org/jdk/commit/acd93df612525777656701821338caf9c81e5a6a
Stats:     37 lines in 5 files changed: 20 ins; 7 del; 10 mod

8355080: java.base/jdk.internal.foreign.SystemLookup.find() doesn't work on static JDK

Reviewed-by: mcimadamore, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/24801

From bchristi at openjdk.org  Mon Apr 28 18:58:47 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 28 Apr 2025 18:58:47 GMT
Subject: RFR: 8355632: WhiteBox.waitForReferenceProcessing() fails assert
 for return type
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 26 Apr 2025 00:10:04 GMT, Stuart Marks  wrote:

>> The newly-added `WhiteBox.waitForReferenceProcessing()` (see [8305186](https://bugs.openjdk.org/browse/JDK-8305186)) always fails with assertions enabled.
>> I've updated the assertion, and also added the test I used locally to test the new method (just not with assertions enabled, apparently.)
>
> test/lib/jdk/test/whitebox/WhiteBox.java line 572:
> 
>> 570:         wfrp = Reference.class.getDeclaredMethod("waitForReferenceProcessing");
>> 571:         wfrp.setAccessible(true);
>> 572:         assert wfrp.getReturnType().equals(Class.forPrimitiveName("boolean"));
> 
> Does `boolean.class` work?

Yes, thanks

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24892#discussion_r2064328929

From mullan at openjdk.org  Mon Apr 28 18:59:53 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Apr 2025 18:59:53 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: 
References: 
 <9rWMdJ_KuW5Auws9DtD_pOWt2Mb4-nGLBDmN0DLFA_0=.c8106398-609d-482d-a5bf-b8b78bb8144d@github.com>
 
 
 
Message-ID: 

On Wed, 23 Apr 2025 13:07:31 GMT, Artur Barashev  wrote:

>> A lot of (existing) HttpClient tests in `test/jdk/java/net/httpclient` currently use this `SimpleSSLContext` construct to read the `testkeys` keystore that's available in the JDK repo's test directory. Moving to a dynamically created keystore instead of a keystore that's committed in the JDK repo seems reasonable. I think it would be better to do that as a separate task in future, since that would involve updating these existing tests to use this new mechanism too.
>
> Sounds good, this was just FYI.

I may be wrong, but it seems you only re-enable 3DES to test a non-TLS 1.3 cipher suite. But you don't have to use a 3DES suite to do that, you could use one of the suites that are already enabled (and are still considered strong), like "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256".

As a general comment, I would avoid re-enabling broken or disabled algorithms unless you specifically have to test that algorithm for some reason.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2064329287

From mullan at openjdk.org  Mon Apr 28 18:59:56 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Apr 2025 18:59:56 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
References: 
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
Message-ID: 

On Thu, 24 Apr 2025 16:59:45 GMT, Daniel Fuchs  wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement 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 409 commits:
> 
>  - merge latest changes from master branch
>  - http3: add missing 
 separator to Http3DiscoveryMode.ALT_SVC API documentation
>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>  - http3: minor improvement to log message
>  - http3: Artur's review - remove commented out code from test
>  - http3: Artur's review - make methods package private
>  - http3: qpack - allow 0 capacity when max capacity is 0
>  - Remove flow control from stream limit comments
>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe

test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 130:

> 128:                             + "expect UnsupportedProtocolVersionException",
> 129:                     () -> connect(uriString, new SSLParameters(
> 130:                             new String[] { "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA" },

Shouldn't this be "TLS_AES_128_GCM_SHA256" (per the test comment above)?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2064322739

From bchristi at openjdk.org  Mon Apr 28 19:21:05 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 28 Apr 2025 19:21:05 GMT
Subject: RFR: 8355632: WhiteBox.waitForReferenceProcessing() fails assert
 for return type [v2]
In-Reply-To: 
References: 
Message-ID: 

> The newly-added `WhiteBox.waitForReferenceProcessing()` (see [8305186](https://bugs.openjdk.org/browse/JDK-8305186)) always fails with assertions enabled.
> I've updated the assertion, and also added the test I used locally to test the new method (just not with assertions enabled, apparently.)

Brent Christian has updated the pull request incrementally with four additional commits since the last revision:

 - move test
 - rename test class
 - enable assertions on test itself
 - use boolean.class

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24892/files
  - new: https://git.openjdk.org/jdk/pull/24892/files/0931c0b3..b8dce1ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24892&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24892&range=00-01

  Stats: 61 lines in 3 files changed: 30 ins; 30 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24892/head:pull/24892

PR: https://git.openjdk.org/jdk/pull/24892

From bchristi at openjdk.org  Mon Apr 28 19:21:06 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 28 Apr 2025 19:21:06 GMT
Subject: RFR: 8355632: WhiteBox.waitForReferenceProcessing() fails assert
 for return type [v2]
In-Reply-To: <7uq7PHOFSjfI7edckxGfoYsHjJJ9ba-VkV1t7nCIriE=.7a92c288-b3b6-482d-97c4-79552cd43c95@github.com>
References: 
 
 <7uq7PHOFSjfI7edckxGfoYsHjJJ9ba-VkV1t7nCIriE=.7a92c288-b3b6-482d-97c4-79552cd43c95@github.com>
Message-ID: 

On Sat, 26 Apr 2025 09:22:30 GMT, Kim Barrett  wrote:

>> test/hotspot/jtreg/vmTestbase/gc/gctests/ReferencesGC/WaitForRefProTest.java line 1:
>> 
>>> 1: /*
>> 
>> Wrong place for this test. vmTestbase is old tests, converted from an old testing infrastructure.
>> See the readme here:  https://github.com/openjdk/jdk/tree/master/test/hotspot/jtreg/vmTestbase
>> In particular, at the bottom of that page: "New tests must *not* be added into this directory."
>> 
>> This new test belongs in `test/lib-test/jdk/test/whitebox/`.
>
> Also, s/Pro/Proc/ in the name of the test.

Sounds good, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24892#discussion_r2064366407

From ihse at openjdk.org  Mon Apr 28 19:50:52 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 28 Apr 2025 19:50:52 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: 
References: 
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
 
Message-ID: 

On Mon, 28 Apr 2025 08:30:43 GMT, Maurizio Cimadamore  wrote:

>> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
>>  - Address henryjen@ comment:
>>    - Remove '#include '.
>
> The changes here look good. Essentially, if `syslookup` is statically linked, trying to do a `dlopen` on it will fail, as the shared library for it doesn't exist. For this reason, this PR seems to "upgrade" syslookup to a JNI library. The presence of the `JNI_OnLoad_syslookup` is then used, as per [JEP 178](https://openjdk.org/jeps/178) to determine whether `syslookup` is a "builtin" library -- that is, a library for which no dynamic linking should occur.
> 
> The loaded library is associated with the boot classloader. This could be problematic, in principle. However, since the requests to `loadLibrary` also come from the boot loader (they are from the `SystemLookup` class) it all works out ok.
> 
> Having to upgrade to JNI is a bit sad -- although I get that it is required as a workaround for now. For the longer term I'd prefer a better way to integrate static lookups in the FFM API. For instance, all `JNI::loadLibrary` does when it comes to static libraries is to return the so called "process handle" -- e.g. a handle to the running process (the JVM). If there was a way to retrieve such a handle (e.g. via a dedicated `SymbolLookup` factory) it would be possible to avoid the JNI dance: just get the process symbol lookup, and look for statically linked symbols in there.

@mcimadamore 

> Having to upgrade to JNI is a bit sad 

I'm not quite sure what you mean that "upgrades" the library to a "JNI library"? Nor why this is sad?

What we do is that we add a marker to identify the library as a built-in library. The name of the marker contains the letters `JNI`, but that is the only JNI thing about it. As Jiangli says, we have added this marker for all other internal JDK libraries. I agree that the name could have been better, but it seems like a minor detail.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2836346969

From vklang at openjdk.org  Mon Apr 28 19:51:46 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 28 Apr 2025 19:51:46 GMT
Subject: RFR: 8355726: LinkedBlockingDeque fixes and improvements
In-Reply-To: <-uuhMy2nvaxxNiV1XvPA4xRLBcG5_nxPfrFAOgWkCuw=.d8cfce6d-4574-4523-8745-3c0c00fc03a3@github.com>
References: 
 <-uuhMy2nvaxxNiV1XvPA4xRLBcG5_nxPfrFAOgWkCuw=.d8cfce6d-4574-4523-8745-3c0c00fc03a3@github.com>
Message-ID: <28zYxPT9ThZCBtcv495mA0cm7Oc98k-bJBp_AAbpvT0=.fe5a43ff-5301-4252-ae45-d9a031110c92@github.com>

On Mon, 28 Apr 2025 15:33:50 GMT, kabutz  wrote:

>> We logged several bugs on the LinkedBlockingDeque. This aggregates them into a single bug report and PR.
>> 
>> 1. LinkedBlockingDeque does not immediately throw InterruptedException in put/take
>> 
>> The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down.
>> 
>> 2. LinkedBlockingDeque.clear() should preserve weakly-consistent iterators
>> 
>> LinkedBlockingDeque.clear() should preserve weakly-consistent iterators by linking f.prev and f.next back to f, allowing the iterators to continue from the first or last respectively. This would be consistent with how the other node-based weakly consistent queues LinkedBlockingQueue LinkedTransferQueue, ConcurrentLinkedQueue/Deque work.
>> 
>> The LBD already supports self-linking, since that is done by the unlinkFirst() and unlinkLast() methods, and the iterators and spliterator thus all support self-linking.
>> 
>> This can be fixed very easily by linking both f.prev and f.next back to f.
>> 
>> 3. LinkedBlockingDeque offer() creates nodes even if capacity has been reached
>> 
>> In the JavaDoc of LinkedBlockingDeque, it states: "Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity." However, in the current implementation, nodes are always created, even if the deque is full. This is because count is non-volatile, and we only check inside the linkFirst/Last() methods whether the queue is full. At this point we have already locked and have created the Node. Instead, the count could be volatile, and we could check before locking.
>> 
>> In the current version, calling offer() on a full LinkedBlockingDeque creates unnecessary objects and contention. Similarly for poll() and peek(), we could exit prior to locking by checking the count field.
>> 
>> 4. LinkedBlockingDeque allows us to overflow size with addAll()
>> 
>> In LinkedBlockingDeque.addAll() we first build up the chain of nodes and then add that chain in bulk to the existing nodes. We count the nodes in "int n" and then whilst hol...
>
> @viktorklang-ora @DougLea @AlanBateman

@kabutz Thanks for opening this PR?just confirming that it's on my to-review queue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24925#issuecomment-2836347292

From vlivanov at openjdk.org  Mon Apr 28 19:52:20 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 28 Apr 2025 19:52:20 GMT
Subject: RFR: 8355689: Wrong native entry name for FloatMaxVector vector math
 stubs with -XX:MaxVectorSize=8
Message-ID: 

Both SVML and SLEEF libraries reuse 128-bit versions for vector of 2 floats. Usually, only `Float64Vector` shape satisfies that condiditon, but with`-XX:MaxVectorSize=8` `FloatMaxVector` becomes 2 element vector as well. 

Adjust the relevant logic to match vector of 2 floats shape structurally. 

Testing: failing regression test, hs-tier1 - hs-tier4

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/24936/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24936&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355689
  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24936.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24936/head:pull/24936

PR: https://git.openjdk.org/jdk/pull/24936

From rriggs at openjdk.org  Mon Apr 28 20:04:48 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 28 Apr 2025 20:04:48 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 26 Apr 2025 19:44:02 GMT, Chen Liang  wrote:

>> Some AccessFlag parsing methods throw IAE because a flag mask is not valid in a location. However, there is no easy way to check what flag mask bits or what flags are valid for a location. We need such APIs to check, specific to each class file format version.
>> 
>> Also in the investigation, it's noted that `ACC_SYNTHETIC` is incorrectly represented - it is available since release 5.0 instead of release 7. This bug is fixed together for implementation simplicity.
>> 
>> The new methods are all in `AccessFlag.Location`:
>> - `Set flags()`
>> - `int flagsMask()`
>> - `Set flags(ClassFileFormatVersion)`
>> - `int flagsMask(ClassFileFormatVersion)`
>> 
>> Also there is some simplification to `AccessFlag` itself to remove the anonymous classes, which should be more startup-friendly.
>> 
>> Testing: Tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix iterator missing NSEE

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 345:

> 343:      * 

> 344:      * This method may return an empty set if the flag is not defined in
> 345:      * the current class file format version.

"may" is conditional, but the empty set is always returned when the flag is not specified.
Suggestion:

     * This method returns an empty set if the flag is not defined in
     * the current class file format version.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 356:

> 354:      * 

> 355:      * This method may return an empty set if the flag is not defined in
> 356:      * the given {@code cffv}.

Suggestion:

     * This method returns an empty set if the flag is not defined in
     * the given {@code cffv}.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 634:

> 632:          * 

> 633:          * This method may return {@code 0} if the structure does not exist in
> 634:          * the given {@code cffv}.

Suggestion:

         * {@return the union of masks of all access flags defined for
         * this location in the given class file format version}
         * 

         * This method returns {@code 0} if there are no access flags in
         * the given {@code cffv}.

The word structure seems out of place and indefinite.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 649:

> 647:          * 

> 648:          * This method may return an empty set if the structure does not exist
> 649:          * in the current class file format version.

Suggestion:

         * {@return The set of {@code AccessFlags} defined for this location in the current class file format version}
         * 

         * This method returns an empty set if the structure does not exist
         * in the current class file format version.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 662:

> 660:          * 

> 661:          * This method may return an empty set if the structure does not exist
> 662:          * in the given {@code cffv}.

Suggestion:

         * {@return The set of  {@code AccessFlags} defined for this location in the given class file format version}
         * 

         * This method returns an empty set if the structure does not exist
         * in the given {@code cffv}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23095#discussion_r2064414287
PR Review Comment: https://git.openjdk.org/jdk/pull/23095#discussion_r2064408776
PR Review Comment: https://git.openjdk.org/jdk/pull/23095#discussion_r2064445683
PR Review Comment: https://git.openjdk.org/jdk/pull/23095#discussion_r2064448181
PR Review Comment: https://git.openjdk.org/jdk/pull/23095#discussion_r2064450751

From liach at openjdk.org  Mon Apr 28 20:08:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 20:08:52 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v8]
In-Reply-To: 
References: 
 
 
Message-ID: <2AcVKtriaOiP1SylC0erah71TGmTaaRQzYZYeYWWHfw=.9b55754d-de67-47f9-b740-c80d3df167e9@github.com>

On Mon, 28 Apr 2025 19:56:23 GMT, Roger Riggs  wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix iterator missing NSEE
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 634:
> 
>> 632:          * 

>> 633:          * This method may return {@code 0} if the structure does not exist in
>> 634:          * the given {@code cffv}.
> 
> Suggestion:
> 
>          * {@return the union of masks of all access flags defined for
>          * this location in the given class file format version}
>          * 

>          * This method returns {@code 0} if there are no access flags in
>          * the given {@code cffv}.
> 
> The word structure seems out of place and indefinite.

I meant "if this location is not present in the given `cffv`" and don't think "no access flags" is the best way to phrase it - consider MODULE location for Java 8.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23095#discussion_r2064460386

From ihse at openjdk.org  Mon Apr 28 20:10:49 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 28 Apr 2025 20:10:49 GMT
Subject: RFR: 8355249: Remove the use of WMIC from the entire source code
 [v2]
In-Reply-To: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com>
References: 
 <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com>
Message-ID: 

On Tue, 22 Apr 2025 07:41:43 GMT, Daishi Tabata  wrote:

>> After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI.
>> 
>> The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency.
>> 
>> Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file.
>> Note: In my environment, it worked correctly even without these options.
>> 
>> The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in:
>> 
>> - `environment.html`: `windows/system/os` section
>> - `process.html`: `[Process ID]/windows/native/info` section
>> 
>> **Testing:**
>> I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes.
>
> Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   run jcheck

make/autoconf/build-performance.m4 line 78:

> 76:   elif test "x$OPENJDK_BUILD_OS" = xwindows; then
> 77:     # Windows, but without cygwin
> 78:     MEMORY_SIZE=`powershell -Command \

We should actually lookup the path of powershell and refer to it as `$POWERSHELL` instead of hard-coding it like this. But I see that the entire BPERF_CHECK_MEMORY_SIZE calls unverified tools on all platforms, and this is not a regression, so I'll let this slip for now.

Are we sure powershell is always installed on Windows?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24791#discussion_r2064464221

From liach at openjdk.org  Mon Apr 28 20:20:28 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 20:20:28 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v9]
In-Reply-To: 
References: 
Message-ID: 

> Some AccessFlag parsing methods throw IAE because a flag mask is not valid in a location. However, there is no easy way to check what flag mask bits or what flags are valid for a location. We need such APIs to check, specific to each class file format version.
> 
> Also in the investigation, it's noted that `ACC_SYNTHETIC` is incorrectly represented - it is available since release 5.0 instead of release 7. This bug is fixed together for implementation simplicity.
> 
> The new methods are all in `AccessFlag.Location`:
> - `Set flags()`
> - `int flagsMask()`
> - `Set flags(ClassFileFormatVersion)`
> - `int flagsMask(ClassFileFormatVersion)`
> 
> Also there is some simplification to `AccessFlag` itself to remove the anonymous classes, which should be more startup-friendly.
> 
> Testing: Tier 1-3

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Wording updates, thanks Roger

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23095/files
  - new: https://git.openjdk.org/jdk/pull/23095/files/f091b912..aa685fcc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23095&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23095&range=07-08

  Stats: 14 lines in 1 file changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/23095.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23095/head:pull/23095

PR: https://git.openjdk.org/jdk/pull/23095

From liach at openjdk.org  Mon Apr 28 20:23:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 20:23:47 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Apr 2025 20:20:28 GMT, Chen Liang  wrote:

>> Some AccessFlag parsing methods throw IAE because a flag mask is not valid in a location. However, there is no easy way to check what flag mask bits or what flags are valid for a location. We need such APIs to check, specific to each class file format version.
>> 
>> Also in the investigation, it's noted that `ACC_SYNTHETIC` is incorrectly represented - it is available since release 5.0 instead of release 7. This bug is fixed together for implementation simplicity.
>> 
>> The new methods are all in `AccessFlag.Location`:
>> - `Set flags()`
>> - `int flagsMask()`
>> - `Set flags(ClassFileFormatVersion)`
>> - `int flagsMask(ClassFileFormatVersion)`
>> 
>> Also there is some simplification to `AccessFlag` itself to remove the anonymous classes, which should be more startup-friendly.
>> 
>> Testing: Tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wording updates, thanks Roger

Thanks for the wording suggestions; I have updated the specification in the CSR as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23095#issuecomment-2836439785

From liach at openjdk.org  Mon Apr 28 20:54:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 20:54:58 GMT
Subject: RFR: 8355775: Improve symbolic sharing in dynamic constant pool
 entries
Message-ID: 

Some dynamic constant pool entries with heavy symbolic descriptors currently don't share them, yet they are used by stack map generation, and computing a new descriptor every time introduces a heavy cost.

This cost is obvious if bytecode generation uses constant dynamic - the stack map generator parses the whole dynamic constant symbol to interpret the return type of an ldc condy, such as in FFM downcalls.

Both the lack of expensive symbol caching in dynamic cp entries and the incorrect query in StackMapGenerator should be fixed.

-------------

Commit messages:
 - Fix the site in StackMapGenerator too
 - Cache symbol for dynamics and copying - useful for stack map generation

Changes: https://git.openjdk.org/jdk/pull/24938/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24938&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355775
  Stats: 105 lines in 6 files changed: 56 ins; 34 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/24938.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24938/head:pull/24938

PR: https://git.openjdk.org/jdk/pull/24938

From iklam at openjdk.org  Mon Apr 28 21:10:46 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 28 Apr 2025 21:10:46 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v4]
In-Reply-To: <2Gy-nNmowCMbzeMWCW2HJasKpxPfTgFwOPUScNd-ywg=.d8d8c09a-e9d9-44a1-b1f0-b4f45047f719@github.com>
References: 
 
 
 
 <2Gy-nNmowCMbzeMWCW2HJasKpxPfTgFwOPUScNd-ywg=.d8d8c09a-e9d9-44a1-b1f0-b4f45047f719@github.com>
Message-ID: 

On Mon, 28 Apr 2025 12:51:13 GMT, Dan Heidinga  wrote:

>> In my mind, `MethodType::prepareForAOTCache()` makes sure all data used by `MethodType` are ready to be cached. `ReferenceKeySet::prepareForAOTCache()` does the same for this particular `ReferenceKeySet` instance.
>> 
>> Potentially we could have
>> 
>> 
>> class MethodType {
>>     static void prepareForAOTCache() {
>>         table1.prepareForAOTCache();
>>         table2.prepareForAOTCache();
>>         ....
>>     }
>> }
>> 
>> 
>> We can have many levels of `prepareForAOTCache()` calls where each level delegates the operations to its sub-components. There are no obvious "frontend/backend" or "interface/implementation" boundaries.
>
> We're creating a set of hooks - right now, there is one in MT - that are called by the VM at the appropriate time during the assembly phase to massage the class's state before we write the AOTCache out.
> 
> Conceptually any class could have a `prepareForAOTCache` method that would act as a front door for the VM to know how to set up its state.  
> 
> Right now we have a hard coded list of one class - MT - that we call `prepareForAOTCache` on.  Another way to implement this would be to loop through all classes that AOTCache candidates and call their `prepareForAOTCache` method (fi they have one).
> 
> If we expand this beyond MT, how does a reader of the code know which classes have VM call-in points and which don't?
> 
> (I'll mention here I missed the static modifier was only on MT which changes the argument a little but I still think different names would be clearer to diffierntiate between what the VM is expected to call and what may happen to the instances)

How about `MethodType::assemblySetup()` for the entry point? This kind of mirrors the `runtimeSetup()` entry points that are called after the AOT cache is loaded. In the future, we can use annotation to mark such entry points to avoid explicit calls from the JVM.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2064743394

From duke at openjdk.org  Mon Apr 28 21:17:02 2025
From: duke at openjdk.org (simon)
Date: Mon, 28 Apr 2025 21:17:02 GMT
Subject: RFR: 8350542: Optional.orElseThrow(Supplier) does not specify behavior
 when supplier returns null
Message-ID: 

Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of another possible cause of a NullPointerException - when the exception supplying function returns a null result.
---------
### Progress
- [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
- [x] Change requires CSR request [JDK-8354953](https://bugs.openjdk.org/browse/JDK-8354953) to be approved
- [x] Change must not contain extraneous whitespace
- [x] Commit message must refer to an issue

### Error
 ?? The pull request body must not be empty.



### Reviewing

Using git

Checkout this PR locally: \
`$ git fetch https://git.openjdk.org/jdk.git pull/23905/head:pull/23905` \
`$ git checkout pull/23905`

Update a local copy of the PR: \
`$ git checkout pull/23905` \
`$ git pull https://git.openjdk.org/jdk.git pull/23905/head`




Using Skara CLI tools

Checkout this PR locally: \
`$ git pr checkout 23905`

View PR using the GUI difftool: \
`$ git pr show -t 23905`




Using diff file

Download this PR as a diff file: \
https://git.openjdk.org/jdk/pull/23905.diff




-------------

Commit messages:
 - 8350542: fix extra trailing space.
 - 8350542: update orElseThrow JavaDoc from CSR specification.
 - 8350542: fix extra trailing space.
 - 8350542: Optional.orElseThrow(Supplier) does not specify behavior when supplier returns null

Changes: https://git.openjdk.org/jdk/pull/23905/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23905&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350542
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23905.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23905/head:pull/23905

PR: https://git.openjdk.org/jdk/pull/23905

From duke at openjdk.org  Mon Apr 28 21:17:02 2025
From: duke at openjdk.org (simon)
Date: Mon, 28 Apr 2025 21:17:02 GMT
Subject: RFR: 8350542: Optional.orElseThrow(Supplier) does not specify
 behavior when supplier returns null
In-Reply-To: 
References: 
Message-ID: 

On Tue, 4 Mar 2025 16:34:19 GMT, simon  wrote:

> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of another possible cause of a NullPointerException - when the exception supplying function returns a null result.
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change requires CSR request [JDK-8354953](https://bugs.openjdk.org/browse/JDK-8354953) to be approved
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> ### Error
>  ?? The pull request body must not be empty.
> 
> 
> 
> ### Reviewing
> 
Using git
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk.git pull/23905/head:pull/23905` \
> `$ git checkout pull/23905`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/23905` \
> `$ git pull https://git.openjdk.org/jdk.git pull/23905/head`
> 
> 

> 
Using Skara CLI tools
> 
> Checkout this PR locally: \
> `$ git pr checkout 23905`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 23905`
> 
> 

> 
Using diff file
> 
> Download this PR as a diff file: \
> https://git.openjdk.org/jdk/pull/23905.diff
> 
> 


@robilad As you asked, I have already sent you an e-mail verify my OCA. I will need for this PR. Cheers, looking forward! ?

The fastest GH's reply was made now! hahaha

Dears, I forgot that Dalibor told me that my OCA verification was not found. So I have just sent it right now. @robilad now you can verify my OCA!

Thank you all for the help. Let's wait for the OCA verify process. Happy to contribute to Java. ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2698302224
PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2752866613
PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2815972016
PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2815989924

From liach at openjdk.org  Mon Apr 28 21:17:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 21:17:02 GMT
Subject: RFR: 8350542: Optional.orElseThrow(Supplier) does not specify
 behavior when supplier returns null
In-Reply-To: 
References: 
Message-ID: <_ZonfKENwIEn5qFBIB9_vBF6yLfzjm59H5YnO4svJJ8=.ad2d2ceb-ff75-4e2f-b98c-095b857a2204@github.com>

On Tue, 4 Mar 2025 16:34:19 GMT, simon  wrote:

> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of another possible cause of a NullPointerException - when the exception supplying function returns a null result.
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change requires CSR request [JDK-8354953](https://bugs.openjdk.org/browse/JDK-8354953) to be approved
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> ### Error
>  ?? The pull request body must not be empty.
> 
> 
> 
> ### Reviewing
> 
Using git
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk.git pull/23905/head:pull/23905` \
> `$ git checkout pull/23905`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/23905` \
> `$ git pull https://git.openjdk.org/jdk.git pull/23905/head`
> 
> 

> 
Using Skara CLI tools
> 
> Checkout this PR locally: \
> `$ git pr checkout 23905`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 23905`
> 
> 

> 
Using diff file
> 
> Download this PR as a diff file: \
> https://git.openjdk.org/jdk/pull/23905.diff
> 
> 


Since this changes API specification text, we will need a small CSR for archival purposes noting the specification change. @RealCLanger since you have assigned yourself on the JBS, you might help with the CSR process too.

You can comment 

> /oca verify

and see if it's handled.

Oops sorry, it should be

> /signed

I think Dalibor might be busy - You might email him again on the progress.

I think we just wait for Dalibor...

Well, now it is the beginning of the OCA verify process...

Don't worry, this is a javadoc (specification) change with no behavioral change, so it can even go into JDK 25 after feature freeze (RDP1)

Also please add some of your own text to the pull request body, like the first sentence of the issue report:

> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of another possible cause of a NullPointerException - when the exception supplying function returns a null result.

Once you have pushed the changes, Chris or I may review this for integration.

src/java.base/share/classes/java/util/Optional.java line 397:

> 395:      * @throws X if no value is present
> 396:      * @throws NullPointerException if no value is present and the exception
> 397:      *         supplying function or produces a {@code null} result

Suggestion:

     *         supplying function is {@code null} or produces a {@code null} result

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2701562566
PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2752822057
PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2752863929
PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2762865417
PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2815460280
PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2815985644
PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2836386345
PR Review Comment: https://git.openjdk.org/jdk/pull/23905#discussion_r2064764964

From duke at openjdk.org  Mon Apr 28 21:17:02 2025
From: duke at openjdk.org (simon)
Date: Mon, 28 Apr 2025 21:17:02 GMT
Subject: RFR: 8350542: Optional.orElseThrow(Supplier) does not specify
 behavior when supplier returns null
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 Mar 2025 16:45:22 GMT, simon  wrote:

> @robilad As you asked, I have already sent you an e-mail verify my OCA. I will need for this PR. Cheers, looking forward! ?

@robilad Any luck into this matter?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2752777225

From duke at openjdk.org  Mon Apr 28 21:17:02 2025
From: duke at openjdk.org (simon)
Date: Mon, 28 Apr 2025 21:17:02 GMT
Subject: RFR: 8350542: Optional.orElseThrow(Supplier) does not specify
 behavior when supplier returns null
In-Reply-To: <_ZonfKENwIEn5qFBIB9_vBF6yLfzjm59H5YnO4svJJ8=.ad2d2ceb-ff75-4e2f-b98c-095b857a2204@github.com>
References: 
 <_ZonfKENwIEn5qFBIB9_vBF6yLfzjm59H5YnO4svJJ8=.ad2d2ceb-ff75-4e2f-b98c-095b857a2204@github.com>
Message-ID: 

On Wed, 26 Mar 2025 00:21:38 GMT, Chen Liang  wrote:

>> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of another possible cause of a NullPointerException - when the exception supplying function returns a null result.
>> ---------
>> ### Progress
>> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
>> - [x] Change requires CSR request [JDK-8354953](https://bugs.openjdk.org/browse/JDK-8354953) to be approved
>> - [x] Change must not contain extraneous whitespace
>> - [x] Commit message must refer to an issue
>> 
>> ### Error
>>  ?? The pull request body must not be empty.
>> 
>> 
>> 
>> ### Reviewing
>> 
Using git
>> 
>> Checkout this PR locally: \
>> `$ git fetch https://git.openjdk.org/jdk.git pull/23905/head:pull/23905` \
>> `$ git checkout pull/23905`
>> 
>> Update a local copy of the PR: \
>> `$ git checkout pull/23905` \
>> `$ git pull https://git.openjdk.org/jdk.git pull/23905/head`
>> 
>> 

>> 
Using Skara CLI tools
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 23905`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 23905`
>> 
>> 

>> 
Using diff file
>> 
>> Download this PR as a diff file: \
>> https://git.openjdk.org/jdk/pull/23905.diff
>> 
>> 

>
> You can comment 
> 
>> /oca verify
> 
> and see if it's handled.

@liach oca appears to be not recognized by bot

> Oops sorry, it should be
> 
>> /signed

@liach I think @robilad didn't verified my account. How should I proceed?

> I think Dalibor might be busy - You might email him again on the progress.

Hello @liach! I'm going to email @robilad.

@liach and @RealCLanger what's the next step to merge this into master?

> Also please add some of your own text to the pull request body, like the first sentence of the issue report:
> 
>> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of another possible cause of a NullPointerException - when the exception supplying function returns a null result.
> 
> Once you have pushed the changes, Chris or I may review this for integration.

@liach now the PR is ready for review. We're almost there! ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2752863934
PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2759919926
PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2763595208
PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2815432182
PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2836690616

From clanger at openjdk.org  Mon Apr 28 21:17:02 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 28 Apr 2025 21:17:02 GMT
Subject: RFR: 8350542: Optional.orElseThrow(Supplier) does not specify
 behavior when supplier returns null
In-Reply-To: 
References: 
Message-ID: <_sKi3jPiMK8pe05b9GCCtTwytLrTphzVPLEl87-Uk4E=.98e3b173-bb33-4d78-a469-01b36ced7a72@github.com>

On Tue, 4 Mar 2025 16:34:19 GMT, simon  wrote:

> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of another possible cause of a NullPointerException - when the exception supplying function returns a null result.
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change requires CSR request [JDK-8354953](https://bugs.openjdk.org/browse/JDK-8354953) to be approved
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> ### Error
>  ?? The pull request body must not be empty.
> 
> 
> 
> ### Reviewing
> 
Using git
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk.git pull/23905/head:pull/23905` \
> `$ git checkout pull/23905`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/23905` \
> `$ git pull https://git.openjdk.org/jdk.git pull/23905/head`
> 
> 

> 
Using Skara CLI tools
> 
> Checkout this PR locally: \
> `$ git pr checkout 23905`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 23905`
> 
> 

> 
Using diff file
> 
> Download this PR as a diff file: \
> https://git.openjdk.org/jdk/pull/23905.diff
> 
> 


I have created a CSR: https://bugs.openjdk.org/browse/JDK-8354953

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2813128214

From clanger at openjdk.org  Mon Apr 28 21:17:02 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 28 Apr 2025 21:17:02 GMT
Subject: RFR: 8350542: Optional.orElseThrow(Supplier) does not specify
 behavior when supplier returns null
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 18 Apr 2025 18:31:41 GMT, simon  wrote:

>> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of another possible cause of a NullPointerException - when the exception supplying function returns a null result.
>> ---------
>> ### Progress
>> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
>> - [x] Change requires CSR request [JDK-8354953](https://bugs.openjdk.org/browse/JDK-8354953) to be approved
>> - [x] Change must not contain extraneous whitespace
>> - [x] Commit message must refer to an issue
>> 
>> ### Error
>>  ?? The pull request body must not be empty.
>> 
>> 
>> 
>> ### Reviewing
>> 
Using git
>> 
>> Checkout this PR locally: \
>> `$ git fetch https://git.openjdk.org/jdk.git pull/23905/head:pull/23905` \
>> `$ git checkout pull/23905`
>> 
>> Update a local copy of the PR: \
>> `$ git checkout pull/23905` \
>> `$ git pull https://git.openjdk.org/jdk.git pull/23905/head`
>> 
>> 

>> 
Using Skara CLI tools
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 23905`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 23905`
>> 
>> 

>> 
Using diff file
>> 
>> Download this PR as a diff file: \
>> https://git.openjdk.org/jdk/pull/23905.diff
>> 
>> 

>
> Thank you all for the help. Let's wait for the OCA verify process. Happy to contribute to Java. ?

@gustavosimon Now the oca seems to be approved and the CSR is progressing. Can you update your change to match the exact specification of the CSR (wording). Please also enable GitHub actions in your fork (https://github.com/gustavosimon/jdk/actions) and merge master to get a current GHA test run (although this change is doc only and no regression is expected).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2835457882

From duke at openjdk.org  Mon Apr 28 21:17:02 2025
From: duke at openjdk.org (simon)
Date: Mon, 28 Apr 2025 21:17:02 GMT
Subject: RFR: 8350542: Optional.orElseThrow(Supplier) does not specify
 behavior when supplier returns null
In-Reply-To: 
References: 
 
 
Message-ID: <6O1Xya3zM1da8p17tPeC20J4Hj6H3lGTgbsDNdMTt9A=.ca459dc9-58dd-4c85-ac47-7f8bc8229c63@github.com>

On Mon, 28 Apr 2025 14:32:59 GMT, Christoph Langer  wrote:

>> Thank you all for the help. Let's wait for the OCA verify process. Happy to contribute to Java. ?
>
> @gustavosimon Now the oca seems to be approved and the CSR is progressing. Can you update your change to match the exact specification of the CSR (wording). Please also enable GitHub actions in your fork (https://github.com/gustavosimon/jdk/actions) and merge master to get a current GHA test run (although this change is doc only and no regression is expected).

@RealCLanger I will do it today. The CSR seems to be approved now - then I just need to push the change to merge it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2836313467

From rriggs at openjdk.org  Mon Apr 28 21:38:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 28 Apr 2025 21:38:52 GMT
Subject: Integrated: 8354335: No longer deprecate wrapper class constructors
 for removal
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Apr 2025 22:05:04 GMT, Roger Riggs  wrote:

> Remove forRemoval = true from @Deprecated annotation of Boolean, Byte, Character, Double, Float, Integer, Long, Short.
> And add `SuppressWarnings("deprecation") `where needed; and remove `SuppressWarnings("removal")`

This pull request has now been integrated.

Changeset: 1fd136cd
Author:    Roger Riggs 
URL:       https://git.openjdk.org/jdk/commit/1fd136cd6b863ebee70e42b2966584218d0919ec
Stats:     22 lines in 9 files changed: 0 ins; 0 del; 22 mod

8354335: No longer deprecate wrapper class constructors for removal

Reviewed-by: liach, bchristi, iris

-------------

PR: https://git.openjdk.org/jdk/pull/24586

From rriggs at openjdk.org  Mon Apr 28 21:57:46 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 28 Apr 2025 21:57:46 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v9]
In-Reply-To: 
References: 
 
Message-ID: <-Cw7ay_i42qgJwJjxHf3FxmjI_GtrYZaU_rTtiMSHv4=.c52cc94a-0a2d-43a7-8d55-7d0d1a4e5781@github.com>

On Mon, 28 Apr 2025 20:20:28 GMT, Chen Liang  wrote:

>> Some AccessFlag parsing methods throw IAE because a flag mask is not valid in a location. However, there is no easy way to check what flag mask bits or what flags are valid for a location. We need such APIs to check, specific to each class file format version.
>> 
>> Also in the investigation, it's noted that `ACC_SYNTHETIC` is incorrectly represented - it is available since release 5.0 instead of release 7. This bug is fixed together for implementation simplicity.
>> 
>> The new methods are all in `AccessFlag.Location`:
>> - `Set flags()`
>> - `int flagsMask()`
>> - `Set flags(ClassFileFormatVersion)`
>> - `int flagsMask(ClassFileFormatVersion)`
>> 
>> Also there is some simplification to `AccessFlag` itself to remove the anonymous classes, which should be more startup-friendly.
>> 
>> Testing: Tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wording updates, thanks Roger

The "kinds of constructs" phrase can be replaced by "Locations" and improve readability.

In AccessFlag.java: 326, there is a pre-existing "integer" that could be removed to be consistent with the other mentions of the mask.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 342:

> 340:     /**
> 341:      * {@return kinds of constructs this flag can be applied to in the
> 342:      * current class file format version}

Suggestion:

     * {@return Locations this flag can be applied to in the
     * current class file format version}

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 352:

> 350: 
> 351:     /**
> 352:      * {@return kinds of constructs this flag can be applied to in the

Suggestion:

     * {@return Locations this flag can be applied to in the

-------------

PR Review: https://git.openjdk.org/jdk/pull/23095#pullrequestreview-2801073592
PR Review Comment: https://git.openjdk.org/jdk/pull/23095#discussion_r2064846060
PR Review Comment: https://git.openjdk.org/jdk/pull/23095#discussion_r2064847670

From rriggs at openjdk.org  Mon Apr 28 22:01:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 28 Apr 2025 22:01:52 GMT
Subject: RFR: 8350542: Optional.orElseThrow(Supplier) does not specify
 behavior when supplier returns null
In-Reply-To: 
References: 
Message-ID: 

On Tue, 4 Mar 2025 16:34:19 GMT, simon  wrote:

> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of another possible cause of a NullPointerException - when the exception supplying function returns a null result.
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change requires CSR request [JDK-8354953](https://bugs.openjdk.org/browse/JDK-8354953) to be approved
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> ### Error
>  ?? The pull request body must not be empty.
> 
> 
> 
> ### Reviewing
> 
Using git
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk.git pull/23905/head:pull/23905` \
> `$ git checkout pull/23905`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/23905` \
> `$ git pull https://git.openjdk.org/jdk.git pull/23905/head`
> 
> 

> 
Using Skara CLI tools
> 
> Checkout this PR locally: \
> `$ git pr checkout 23905`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 23905`
> 
> 

> 
Using diff file
> 
> Download this PR as a diff file: \
> https://git.openjdk.org/jdk/pull/23905.diff
> 
> 


src/java.base/share/classes/java/util/Optional.java line 397:

> 395:      * @throws X if no value is present
> 396:      * @throws NullPointerException if no value is present and the exception
> 397:      *         supplying function or produces a {@code null} result

It seems there is a word missing before the "or".
Suggestion:

     *         supplying function is {@code null} or produces a {@code null} result

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23905#discussion_r2064856833

From liach at openjdk.org  Mon Apr 28 22:07:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 22:07:00 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v10]
In-Reply-To: 
References: 
Message-ID: <1aEF2_HxLIHF1wCtPiukcWJoIl-MV6f-JDWoATi7DzU=.b4433c9e-ec66-4ec3-a595-676e460cec7d@github.com>

> Some AccessFlag parsing methods throw IAE because a flag mask is not valid in a location. However, there is no easy way to check what flag mask bits or what flags are valid for a location. We need such APIs to check, specific to each class file format version.
> 
> Also in the investigation, it's noted that `ACC_SYNTHETIC` is incorrectly represented - it is available since release 5.0 instead of release 7. This bug is fixed together for implementation simplicity.
> 
> The new methods are all in `AccessFlag.Location`:
> - `Set flags()`
> - `int flagsMask()`
> - `Set flags(ClassFileFormatVersion)`
> - `int flagsMask(ClassFileFormatVersion)`
> 
> Also there is some simplification to `AccessFlag` itself to remove the anonymous classes, which should be more startup-friendly.
> 
> Testing: Tier 1-3

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Update specs for other existing APIs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23095/files
  - new: https://git.openjdk.org/jdk/pull/23095/files/aa685fcc..b651e8d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23095&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23095&range=08-09

  Stats: 11 lines in 1 file changed: 1 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/23095.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23095/head:pull/23095

PR: https://git.openjdk.org/jdk/pull/23095

From liach at openjdk.org  Mon Apr 28 22:13:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 22:13:52 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v9]
In-Reply-To: <-Cw7ay_i42qgJwJjxHf3FxmjI_GtrYZaU_rTtiMSHv4=.c52cc94a-0a2d-43a7-8d55-7d0d1a4e5781@github.com>
References: 
 
 <-Cw7ay_i42qgJwJjxHf3FxmjI_GtrYZaU_rTtiMSHv4=.c52cc94a-0a2d-43a7-8d55-7d0d1a4e5781@github.com>
Message-ID: 

On Mon, 28 Apr 2025 21:48:40 GMT, Roger Riggs  wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wording updates, thanks Roger
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 342:
> 
>> 340:     /**
>> 341:      * {@return kinds of constructs this flag can be applied to in the
>> 342:      * current class file format version}
> 
> Suggestion:
> 
>      * {@return Locations this flag can be applied to in the
>      * current class file format version}

FYI we need to use lowercase in this tag, otherwise rendered output would be 

Returns Locations this flag can be applied to in the current class file format version.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23095#discussion_r2064869716

From duke at openjdk.org  Mon Apr 28 22:14:29 2025
From: duke at openjdk.org (simon)
Date: Mon, 28 Apr 2025 22:14:29 GMT
Subject: RFR: 8350542: Optional.orElseThrow(Supplier) does not specify
 behavior when supplier returns null [v2]
In-Reply-To: 
References: 
Message-ID: 

> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of another possible cause of a NullPointerException - when the exception supplying function returns a null result.
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change requires CSR request [JDK-8354953](https://bugs.openjdk.org/browse/JDK-8354953) to be approved
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> ### Error
>  ?? The pull request body must not be empty.
> 
> 
> 
> ### Reviewing
> 
Using git
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk.git pull/23905/head:pull/23905` \
> `$ git checkout pull/23905`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/23905` \
> `$ git pull https://git.openjdk.org/jdk.git pull/23905/head`
> 
> 

> 
Using Skara CLI tools
> 
> Checkout this PR locally: \
> `$ git pr checkout 23905`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 23905`
> 
> 

> 
Using diff file
> 
> Download this PR as a diff file: \
> https://git.openjdk.org/jdk/pull/23905.diff
> 
> 


simon has updated the pull request incrementally with one additional commit since the last revision:

  8350542: update orElseThrow JavaDoc from CSR specification.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23905/files
  - new: https://git.openjdk.org/jdk/pull/23905/files/53df7aff..32448774

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23905&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23905&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23905.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23905/head:pull/23905

PR: https://git.openjdk.org/jdk/pull/23905

From psandoz at openjdk.org  Mon Apr 28 22:18:45 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 28 Apr 2025 22:18:45 GMT
Subject: RFR: 8355689: Wrong native entry name for FloatMaxVector vector
 math stubs with -XX:MaxVectorSize=8
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Apr 2025 19:41:28 GMT, Vladimir Ivanov  wrote:

> Both SVML and SLEEF libraries reuse 128-bit versions for vector of 2 floats. Usually, only `Float64Vector` shape satisfies that condiditon, but with`-XX:MaxVectorSize=8` `FloatMaxVector` becomes 2 element vector as well. 
> 
> Adjust the relevant logic to match vector of 2 floats shape structurally. 
> 
> Testing: failing regression test, hs-tier1 - hs-tier4

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24936#pullrequestreview-2801121976

From duke at openjdk.org  Mon Apr 28 22:20:49 2025
From: duke at openjdk.org (simon)
Date: Mon, 28 Apr 2025 22:20:49 GMT
Subject: RFR: 8350542: Optional.orElseThrow(Supplier) does not specify
 behavior when supplier returns null
In-Reply-To: <_ZonfKENwIEn5qFBIB9_vBF6yLfzjm59H5YnO4svJJ8=.ad2d2ceb-ff75-4e2f-b98c-095b857a2204@github.com>
References: 
 <_ZonfKENwIEn5qFBIB9_vBF6yLfzjm59H5YnO4svJJ8=.ad2d2ceb-ff75-4e2f-b98c-095b857a2204@github.com>
Message-ID: 

On Mon, 28 Apr 2025 20:04:22 GMT, Chen Liang  wrote:

>> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of another possible cause of a NullPointerException - when the exception supplying function returns a null result.
>> ---------
>> ### Progress
>> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
>> - [x] Change requires CSR request [JDK-8354953](https://bugs.openjdk.org/browse/JDK-8354953) to be approved
>> - [x] Change must not contain extraneous whitespace
>> - [x] Commit message must refer to an issue
>> 
>> ### Error
>>  ?? The pull request body must not be empty.
>> 
>> 
>> 
>> ### Reviewing
>> 
Using git
>> 
>> Checkout this PR locally: \
>> `$ git fetch https://git.openjdk.org/jdk.git pull/23905/head:pull/23905` \
>> `$ git checkout pull/23905`
>> 
>> Update a local copy of the PR: \
>> `$ git checkout pull/23905` \
>> `$ git pull https://git.openjdk.org/jdk.git pull/23905/head`
>> 
>> 

>> 
Using Skara CLI tools
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 23905`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 23905`
>> 
>> 

>> 
Using diff file
>> 
>> Download this PR as a diff file: \
>> https://git.openjdk.org/jdk/pull/23905.diff
>> 
>> 

>
> Also please add some of your own text to the pull request body, like the first sentence of the issue report:
> 
>> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of another possible cause of a NullPointerException - when the exception supplying function returns a null result.
> 
> Once you have pushed the changes, Chris or I may review this for integration.

@liach @RogerRiggs Sorry, I forgot a part of the specification! Now we are ready!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2836857568

From jvernee at openjdk.org  Mon Apr 28 22:37:49 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 28 Apr 2025 22:37:49 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v3]
In-Reply-To: 
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 
Message-ID: <-tU7jau3I5Ld4Ngkxe6bhnLQ7NCYU88JmmaaoQK-BqY=.4a6be50e-a81b-4800-9e6f-812c23ded2dc@github.com>

On Mon, 28 Apr 2025 14:36:33 GMT, Chen Liang  wrote:

>> Perf numbers for simple main:
>> Linking of `Class::forName0` down from ~152 to ~83
>> 
>> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
>> JNI: ~45
>> baseline panama: ~164
>> patch: ~103
>> 
>> Also see #24705.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
>  - Use more simple function descriptor
>  - Simplify FFM linker warmup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
>  - Wip work trying to speed up FFM

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24742#pullrequestreview-2801191611

From jvernee at openjdk.org  Mon Apr 28 22:37:50 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 28 Apr 2025 22:37:50 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v2]
In-Reply-To: <_bX7wPu7a39ujK5Wi-iS0IvVEfDHG438lCaNRXhT_R8=.fbad2ac1-97a1-417b-a080-f360f38dc66b@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 
 
 
 <_bX7wPu7a39ujK5Wi-iS0IvVEfDHG438lCaNRXhT_R8=.fbad2ac1-97a1-417b-a080-f360f38dc66b@github.com>
Message-ID: 

On Mon, 28 Apr 2025 14:23:53 GMT, Chen Liang  wrote:

>> That was from the past attempt of linking Class forName0. Tge exact shape doesn't really matter here as we are mainly saving on DMH.
>
> Can I just change this signature to `FunctionDescriptor.ofVoid()`?

Ok, that makes sense. I suppose in the future we might want to pre-generate BindingSpecializer classes, and then it would be useful to figure out which shapes are most common.

I think using `ofVoid()` for now sounds good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2064932240

From jvernee at openjdk.org  Mon Apr 28 22:43:50 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 28 Apr 2025 22:43:50 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: 
References: 
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
 
Message-ID: 

On Mon, 28 Apr 2025 08:30:43 GMT, Maurizio Cimadamore  wrote:

>> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
>>  - Address henryjen@ comment:
>>    - Remove '#include '.
>
> The changes here look good. Essentially, if `syslookup` is statically linked, trying to do a `dlopen` on it will fail, as the shared library for it doesn't exist. For this reason, this PR seems to "upgrade" syslookup to a JNI library. The presence of the `JNI_OnLoad_syslookup` is then used, as per [JEP 178](https://openjdk.org/jeps/178) to determine whether `syslookup` is a "builtin" library -- that is, a library for which no dynamic linking should occur.
> 
> The loaded library is associated with the boot classloader. This could be problematic, in principle. However, since the requests to `loadLibrary` also come from the boot loader (they are from the `SystemLookup` class) it all works out ok.
> 
> Having to upgrade to JNI is a bit sad -- although I get that it is required as a workaround for now. For the longer term I'd prefer a better way to integrate static lookups in the FFM API. For instance, all `JNI::loadLibrary` does when it comes to static libraries is to return the so called "process handle" -- e.g. a handle to the running process (the JVM). If there was a way to retrieve such a handle (e.g. via a dedicated `SymbolLookup` factory) it would be possible to avoid the JNI dance: just get the process symbol lookup, and look for statically linked symbols in there.

> @mcimadamore
> 
> > Having to upgrade to JNI is a bit sad
> 
> I'm not quite sure what you mean that "upgrades" the library to a "JNI library"? Nor why this is sad?

JNI libraries are more restrictive than non-JNI libraries, as JNI libraries can only be loaded by a single class loader. The lifetime of the class loader is re-used as the lifetime of the library, and tells us when OnLoad and OnUnload should be called. This is in particular not needed in this case, and gets us away from the loaded-by-single-class-loader restricted, but as Maurizio says, making this library a JNI library is probably okay, since this class should always be loaded by the boot loader.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2836921541

From erikj at openjdk.org  Mon Apr 28 23:05:45 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 28 Apr 2025 23:05:45 GMT
Subject: RFR: 8355249: Remove the use of WMIC from the entire source code
 [v2]
In-Reply-To: 
References: 
 <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com>
 
Message-ID: <_UAezO_9udU58185ILRhZPrnVaRCM0H4amsoq4Txxiw=.66f164e7-2ffe-4cca-92bd-848ecffb2ff7@github.com>

On Mon, 28 Apr 2025 20:08:00 GMT, Magnus Ihse Bursie  wrote:

> Are we sure powershell is always installed on Windows?

I verified by running tests on all the Windows versions we use internally and looked at the calculated concurrency in RunTest.gmk. If we didn't get a number for memory I believe concurrency would end up as `1`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24791#discussion_r2064977925

From liach at openjdk.org  Mon Apr 28 23:16:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 23:16:48 GMT
Subject: RFR: 8350542: Optional.orElseThrow(Supplier) does not specify
 behavior when supplier returns null [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Apr 2025 22:14:29 GMT, simon  wrote:

>> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of another possible cause of a NullPointerException - when the exception supplying function returns a null result.
>> ---------
>> ### Progress
>> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
>> - [x] Change requires CSR request [JDK-8354953](https://bugs.openjdk.org/browse/JDK-8354953) to be approved
>> - [x] Change must not contain extraneous whitespace
>> - [x] Commit message must refer to an issue
>> 
>> ### Error
>>  ?? The pull request body must not be empty.
>> 
>> 
>> 
>> ### Reviewing
>> 
Using git
>> 
>> Checkout this PR locally: \
>> `$ git fetch https://git.openjdk.org/jdk.git pull/23905/head:pull/23905` \
>> `$ git checkout pull/23905`
>> 
>> Update a local copy of the PR: \
>> `$ git checkout pull/23905` \
>> `$ git pull https://git.openjdk.org/jdk.git pull/23905/head`
>> 
>> 

>> 
Using Skara CLI tools
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 23905`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 23905`
>> 
>> 

>> 
Using diff file
>> 
>> Download this PR as a diff file: \
>> https://git.openjdk.org/jdk/pull/23905.diff
>> 
>> 

>
> simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8350542: update orElseThrow JavaDoc from CSR specification.

Looks good.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23905#pullrequestreview-2801271010

From henryjen at openjdk.org  Mon Apr 28 23:40:11 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 28 Apr 2025 23:40:11 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.

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 three additional commits since the last revision:

 - Merge remote-tracking branch 'openjdk/master' into open
 - Enhance validation output to be more specific
 - 8345431: Detect duplicate entries in jar files with jar --validate

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/cae7f6a2..384905bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=00-01

  Stats: 283063 lines in 2394 files changed: 79465 ins; 194897 del; 8701 mod
  Patch: https://git.openjdk.org/jdk/pull/24430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24430/head:pull/24430

PR: https://git.openjdk.org/jdk/pull/24430

From henryjen at openjdk.org  Mon Apr 28 23:46:44 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 28 Apr 2025 23:46:44 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v2]
In-Reply-To: <-zMJMfesQZoXPso7UCC6fE6k0XN3KDtnIjjz7cEB9xQ=.ab47a4df-f3ac-4d00-9328-e29851789bfc@github.com>
References: 
 
 
 
 
 <-zMJMfesQZoXPso7UCC6fE6k0XN3KDtnIjjz7cEB9xQ=.ab47a4df-f3ac-4d00-9328-e29851789bfc@github.com>
Message-ID: <1FEqZ12LqoPdAYxa-JVYFXEQ89UrP3cNFBCXEToUNBw=.2d7d32d8-84d0-4a57-84d1-010298f20b8a@github.com>

On Fri, 4 Apr 2025 16:41:52 GMT, Lance Andersen  wrote:

>> Yes, in a perfect world there will be a 1 to 1 match but either way we should sanity check it in case something happened
>
>> Is the ordering required by ZIP or Jar format? We can certainly do that if that's under spec and not an implementation detail.
> 
> The Zip Spec states the following:
> 
> 
>> 4.3.2 Each file placed into a ZIP file MUST be preceded by  a "local 
>>    file header" record for that file.  Each "local file header" MUST be 
>>    accompanied by a corresponding "central directory header" record within 
>>    the central directory section of the ZIP file.
> 
> That being said I am not aware of any implementations  where the order is different given you have to generate the LOC prior to the CEN and End of CEN

I had add a warning on ordering mismatch, but still consider the jar valid.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2065037608

From liach at openjdk.org  Tue Apr 29 00:08:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 00:08:47 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Apr 2025 23:40:11 GMT, Henry Jen  wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> 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 three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Enhance validation output to be more specific
>  - 8345431: Detect duplicate entries in jar files with jar --validate

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 89:

> 87: 
> 88:     // Check if CEN contains the LOC entry by name
> 89:     private boolean checkHasCenEntry(String locEntryName) {

This method name and comment does not indicate a match is removed like the name `Next` in `checkNextCenEntry` implies - I suggest some way to indicate that a match is removed, like `checkUnorderedCenEntry`. `Has` implies a read-only operation that performs no modification.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2065075115

From duke at openjdk.org  Tue Apr 29 00:18:54 2025
From: duke at openjdk.org (duke)
Date: Tue, 29 Apr 2025 00:18:54 GMT
Subject: RFR: 8350542: Optional.orElseThrow(Supplier) does not specify
 behavior when supplier returns null [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Apr 2025 22:14:29 GMT, simon  wrote:

>> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of another possible cause of a NullPointerException - when the exception supplying function returns a null result.
>> ---------
>> ### Progress
>> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
>> - [x] Change requires CSR request [JDK-8354953](https://bugs.openjdk.org/browse/JDK-8354953) to be approved
>> - [x] Change must not contain extraneous whitespace
>> - [x] Commit message must refer to an issue
>> 
>> ### Error
>>  ?? The pull request body must not be empty.
>> 
>> 
>> 
>> ### Reviewing
>> 
Using git
>> 
>> Checkout this PR locally: \
>> `$ git fetch https://git.openjdk.org/jdk.git pull/23905/head:pull/23905` \
>> `$ git checkout pull/23905`
>> 
>> Update a local copy of the PR: \
>> `$ git checkout pull/23905` \
>> `$ git pull https://git.openjdk.org/jdk.git pull/23905/head`
>> 
>> 

>> 
Using Skara CLI tools
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 23905`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 23905`
>> 
>> 

>> 
Using diff file
>> 
>> Download this PR as a diff file: \
>> https://git.openjdk.org/jdk/pull/23905.diff
>> 
>> 

>
> simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8350542: update orElseThrow JavaDoc from CSR specification.

@gustavosimon 
Your change (at version 324487742d5b8c2b543e67ee7a8039594f31b624) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2837079006

From duke at openjdk.org  Tue Apr 29 00:18:55 2025
From: duke at openjdk.org (simon)
Date: Tue, 29 Apr 2025 00:18:55 GMT
Subject: RFR: 8350542: Optional.orElseThrow(Supplier) does not specify
 behavior when supplier returns null
In-Reply-To: <_ZonfKENwIEn5qFBIB9_vBF6yLfzjm59H5YnO4svJJ8=.ad2d2ceb-ff75-4e2f-b98c-095b857a2204@github.com>
References: 
 <_ZonfKENwIEn5qFBIB9_vBF6yLfzjm59H5YnO4svJJ8=.ad2d2ceb-ff75-4e2f-b98c-095b857a2204@github.com>
Message-ID: <4-uIbQLOA-5MYadRjAI2psspW4sFXXCQhUn-dtp2qLk=.81115c0d-4643-492a-a1ca-ab2363cde17d@github.com>

On Mon, 28 Apr 2025 20:04:22 GMT, Chen Liang  wrote:

>> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of another possible cause of a NullPointerException - when the exception supplying function returns a null result.
>> ---------
>> ### Progress
>> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
>> - [x] Change requires CSR request [JDK-8354953](https://bugs.openjdk.org/browse/JDK-8354953) to be approved
>> - [x] Change must not contain extraneous whitespace
>> - [x] Commit message must refer to an issue
>> 
>> ### Error
>>  ?? The pull request body must not be empty.
>> 
>> 
>> 
>> ### Reviewing
>> 
Using git
>> 
>> Checkout this PR locally: \
>> `$ git fetch https://git.openjdk.org/jdk.git pull/23905/head:pull/23905` \
>> `$ git checkout pull/23905`
>> 
>> Update a local copy of the PR: \
>> `$ git checkout pull/23905` \
>> `$ git pull https://git.openjdk.org/jdk.git pull/23905/head`
>> 
>> 

>> 
Using Skara CLI tools
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 23905`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 23905`
>> 
>> 

>> 
Using diff file
>> 
>> Download this PR as a diff file: \
>> https://git.openjdk.org/jdk/pull/23905.diff
>> 
>> 

>
> Also please add some of your own text to the pull request body, like the first sentence of the issue report:
> 
>> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of another possible cause of a NullPointerException - when the exception supplying function returns a null result.
> 
> Once you have pushed the changes, Chris or I may review this for integration.

@liach Can't I integrate?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2837084279

From duke at openjdk.org  Tue Apr 29 01:35:49 2025
From: duke at openjdk.org (erifan)
Date: Tue, 29 Apr 2025 01:35:49 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 28 Apr 2025 14:10:40 GMT, Emanuel Peter  wrote:

>> test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java line 237:
>> 
>>> 235:     public static void testCompareEQMaskNotByte() {
>>> 236:         testCompareMaskNotByte(VectorOperators.EQ);
>>> 237:     }
>> 
>> Another comment: you now only have "negative" tests, where you check for count `=0`. It would be good if you also had a positive rule here, one where you do see an XOR in a similar case, where your optimization does apply.
>> 
>> This would basically be a "control" that checks that your are testing the right thing.
>
> Also: this test should vectorize on some plarforms, right? A compare, correct? Would it not be good to actively check that with an IR rule?

> Another comment: you now only have "negative" tests, where you check for count =0. It would be good if you also had a positive rule here, one where you do see an XOR in a similar case, where your optimization does apply.
This would basically be a "control" that checks that your are testing the right thing.

This is not a negative test, this is a positive test. What this patch does is:

`Vector compare(NE) + not() => vector compare(EQ)`. The `not()` operation is removed. For details, please see the commit message and related code. So here we check XorV and XorVMask == 0, which I think is reasonable.

For negative tests, I think it's not necessary, because I only test what I optimized, and I won't write a test to say what optimization cannot be done.

> Also: this test should vectorize on some plarforms, right? A compare, correct? Would it not be good to actively check that with an IR rule?

The `compare` operation is not eliminated, the patch aims to eliminate the `not` operation following `compare`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2065195738

From duke at openjdk.org  Tue Apr 29 01:55:46 2025
From: duke at openjdk.org (erifan)
Date: Tue, 29 Apr 2025 01:55:46 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v2]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
Message-ID: 

On Mon, 28 Apr 2025 14:12:02 GMT, Emanuel Peter  wrote:

> I suppose in that case you can assert that you NEVER get those nodes, because if you have vectors not supported, they will not show up because of that, and if you do support vectors, they should be optimized away.

This is expected. 

- If vectors are supported, the test checks that Vector not() is optimized away.

- If vectors are not supported, the vector IRs won't generated, so the IR check will pass. And the correctness verification also runs, this is used to ensure that the patch does not break correctness. In the future if vectors are supported, the test also runs without any modification.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2065211944

From haosun at openjdk.org  Tue Apr 29 02:03:43 2025
From: haosun at openjdk.org (Hao Sun)
Date: Tue, 29 Apr 2025 02:03:43 GMT
Subject: RFR: 8355689: Wrong native entry name for FloatMaxVector vector
 math stubs with -XX:MaxVectorSize=8
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Apr 2025 19:41:28 GMT, Vladimir Ivanov  wrote:

> Both SVML and SLEEF libraries reuse 128-bit versions for vector of 2 floats. Usually, only `Float64Vector` shape satisfies that condiditon, but with`-XX:MaxVectorSize=8` `FloatMaxVector` becomes 2 element vector as well. 
> 
> Adjust the relevant logic to match vector of 2 floats shape structurally. 
> 
> Testing: failing regression test, hs-tier1 - hs-tier4

Marked as reviewed by haosun (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24936#pullrequestreview-2801600208

From kvn at openjdk.org  Tue Apr 29 02:20:55 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 29 Apr 2025 02:20:55 GMT
Subject: RFR: 8355689: Wrong native entry name for FloatMaxVector vector
 math stubs with -XX:MaxVectorSize=8
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Apr 2025 19:41:28 GMT, Vladimir Ivanov  wrote:

> Both SVML and SLEEF libraries reuse 128-bit versions for vector of 2 floats. Usually, only `Float64Vector` shape satisfies that condiditon, but with`-XX:MaxVectorSize=8` `FloatMaxVector` becomes 2 element vector as well. 
> 
> Adjust the relevant logic to match vector of 2 floats shape structurally. 
> 
> Testing: failing regression test, hs-tier1 - hs-tier4

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24936#pullrequestreview-2801643540

From duke at openjdk.org  Tue Apr 29 02:45:46 2025
From: duke at openjdk.org (erifan)
Date: Tue, 29 Apr 2025 02:45:46 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v3]
In-Reply-To: <41Y44tSReVYSBYslzzcs-GGyQ6SPM2CfTkJ3-MpGBYM=.cbb47073-5d30-4391-9d67-b2fa758f4dca@github.com>
References: 
 
 
 
 
 
 <41Y44tSReVYSBYslzzcs-GGyQ6SPM2CfTkJ3-MpGBYM=.cbb47073-5d30-4391-9d67-b2fa758f4dca@github.com>
Message-ID: <5OOJ1Arw03ZOr1T6BhfQSTNL2SShAuJGxhXep1HweGU=.f9a59f0d-f9d0-4e91-b37b-9460089accbf@github.com>

On Mon, 28 Apr 2025 14:13:43 GMT, Emanuel Peter  wrote:

> > > > > Just a drive-by comment for now, I may review this later more fully.
> > > > > > I would also prefer if you added the IR restrictions rather than the JTREG requires.
> > > > > > The benefit is that we can still run the tests on all platforms, at least for result verification.
> > > > > > Imagine someone adds optimizations to a new platform, but does not know about this test here. They make a mistake, and there is a bug, leading either to a crash or wrong result. With the requires, you test would never even run, and we would not catch it. With the IR applyIf, we would catch the bug.
> > > > > 
> > > > > 
> > > > > Just copy pasting the IR applyIf everywhere is not that much work, and adding in a new platform later is not really hard either.
> > > > 
> > > > 
> > > > Thanks! The problem is that when a new platform is added, people may not even know there is a test.
> > > 
> > > 
> > > @erifan That is true. But we have that problem either way. If you use `@require`, then the person does not realize there is a test AND the test is not run. If you use `applyIf`, the person does not realize there is a test, but it is run at least for result verifiation - and then the person MIGHT realize if the test catches a wrong result / crash.
> > 
> > 
> > This test will run on new platforms when we use @requires. I explained the meaning of the @requires in the previous comment, it only excludes one case: when -XX:UseAVX=0 is specified on x86 platforms.
> 
> I see. You should probably add a comment there, to say that you are only excluding `AVX=0`. But even `UseAVX = 0` would profit from result verification.

@requires is a special comment itself. I feel like it's a bit weird to add a comment to a comment, and I don't think the @requires is hard to understand.

If we want to verify the correctness of AVX=0, we have to use ApplyIf. This is back to the beginning of the question, should we use @requires or ApplyIf? Personally I tend to use the former. By the way, I have tested the correctness of AVX=0 locally.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-2837292655

From liach at openjdk.org  Tue Apr 29 03:08:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 03:08:52 GMT
Subject: RFR: 8342206: Convenience method to check if a constant pool entry
 matches nominal descriptors [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 25 Apr 2025 16:36:53 GMT, Chen Liang  wrote:

>> The ClassFile API promotes usage of constant nominal descriptors over literal strings. However, for `class` file parsing, currently the efficient way to check if a constant pool entry matches a desired descriptor is via unrolling them back to strings. However, string unrolling is ugly, and often times confusing, such as internal names versus field descriptors.
>> 
>> As a result, I propose to provide new methods that compare constant pool entries with the potential symbolic descriptors they represent. This is no less efficient as checking raw string equality, avoids exceptional failure behaviors of conversion to symbolic descriptors, and avoids potential programmer errors stemming from raw string handling. See the CSR for a full story.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Extract the actual tests, move pool entry spawning to the bottom
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cf-equals-sym
>  - Rename UTF8 test methods to be different from other test methods
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cf-equals-sym
>  - 8342206: Convenience method to check if a constant pool entry matches nominal descriptors

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23548#issuecomment-2837316629

From liach at openjdk.org  Tue Apr 29 03:08:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 03:08:53 GMT
Subject: Integrated: 8342206: Convenience method to check if a constant pool
 entry matches nominal descriptors
In-Reply-To: 
References: 
Message-ID: 

On Tue, 11 Feb 2025 02:26:57 GMT, Chen Liang  wrote:

> The ClassFile API promotes usage of constant nominal descriptors over literal strings. However, for `class` file parsing, currently the efficient way to check if a constant pool entry matches a desired descriptor is via unrolling them back to strings. However, string unrolling is ugly, and often times confusing, such as internal names versus field descriptors.
> 
> As a result, I propose to provide new methods that compare constant pool entries with the potential symbolic descriptors they represent. This is no less efficient as checking raw string equality, avoids exceptional failure behaviors of conversion to symbolic descriptors, and avoids potential programmer errors stemming from raw string handling. See the CSR for a full story.

This pull request has now been integrated.

Changeset: e4cb49fc
Author:    Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/e4cb49fc8531ee7cdc66ed16f5f5e2ec94d1244b
Stats:     440 lines in 9 files changed: 422 ins; 8 del; 10 mod

8342206: Convenience method to check if a constant pool entry matches nominal descriptors

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/23548

From clanger at openjdk.org  Tue Apr 29 04:19:54 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 29 Apr 2025 04:19:54 GMT
Subject: RFR: 8350542: Optional.orElseThrow(Supplier) does not specify
 behavior when supplier returns null [v2]
In-Reply-To: 
References: 
 
Message-ID: <0RH21wr2aV_BSOsSKmYD_My3_L7v5C6fjvkjE4LIzdo=.23385ade-ee5f-48bb-ba2f-32ad4c0af993@github.com>

On Mon, 28 Apr 2025 22:14:29 GMT, simon  wrote:

>> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of another possible cause of a NullPointerException - when the exception supplying function returns a null result.
>> ---------
>> ### Progress
>> - [x] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
>> - [x] Change requires CSR request [JDK-8354953](https://bugs.openjdk.org/browse/JDK-8354953) to be approved
>> - [x] Change must not contain extraneous whitespace
>> - [x] Commit message must refer to an issue
>> 
>> ### Error
>>  ?? The pull request body must not be empty.
>> 
>> 
>> 
>> ### Reviewing
>> 
Using git
>> 
>> Checkout this PR locally: \
>> `$ git fetch https://git.openjdk.org/jdk.git pull/23905/head:pull/23905` \
>> `$ git checkout pull/23905`
>> 
>> Update a local copy of the PR: \
>> `$ git checkout pull/23905` \
>> `$ git pull https://git.openjdk.org/jdk.git pull/23905/head`
>> 
>> 

>> 
Using Skara CLI tools
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 23905`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 23905`
>> 
>> 

>> 
Using diff file
>> 
>> Download this PR as a diff file: \
>> https://git.openjdk.org/jdk/pull/23905.diff
>> 
>> 

>
> simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8350542: update orElseThrow JavaDoc from CSR specification.

Marked as reviewed by clanger (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23905#pullrequestreview-2801915033

From clanger at openjdk.org  Tue Apr 29 04:19:55 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 29 Apr 2025 04:19:55 GMT
Subject: RFR: 8350542: Optional.orElseThrow(Supplier) does not specify
 behavior when supplier returns null
In-Reply-To: <_ZonfKENwIEn5qFBIB9_vBF6yLfzjm59H5YnO4svJJ8=.ad2d2ceb-ff75-4e2f-b98c-095b857a2204@github.com>
References: 
 <_ZonfKENwIEn5qFBIB9_vBF6yLfzjm59H5YnO4svJJ8=.ad2d2ceb-ff75-4e2f-b98c-095b857a2204@github.com>
Message-ID: 

On Mon, 28 Apr 2025 20:04:22 GMT, Chen Liang  wrote:

>> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of another possible cause of a NullPointerException - when the exception supplying function returns a null result.
>> ---------
>> ### Progress
>> - [x] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
>> - [x] Change requires CSR request [JDK-8354953](https://bugs.openjdk.org/browse/JDK-8354953) to be approved
>> - [x] Change must not contain extraneous whitespace
>> - [x] Commit message must refer to an issue
>> 
>> ### Error
>>  ?? The pull request body must not be empty.
>> 
>> 
>> 
>> ### Reviewing
>> 
Using git
>> 
>> Checkout this PR locally: \
>> `$ git fetch https://git.openjdk.org/jdk.git pull/23905/head:pull/23905` \
>> `$ git checkout pull/23905`
>> 
>> Update a local copy of the PR: \
>> `$ git checkout pull/23905` \
>> `$ git pull https://git.openjdk.org/jdk.git pull/23905/head`
>> 
>> 

>> 
Using Skara CLI tools
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 23905`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 23905`
>> 
>> 

>> 
Using diff file
>> 
>> Download this PR as a diff file: \
>> https://git.openjdk.org/jdk/pull/23905.diff
>> 
>> 

>
> Also please add some of your own text to the pull request body, like the first sentence of the issue report:
> 
>> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of another possible cause of a NullPointerException - when the exception supplying function returns a null result.
> 
> Once you have pushed the changes, Chris or I may review this for integration.

> @liach Can't I integrate?

When you are not a committer, some committer needs to sponsor it for you. I'm doing it. ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23905#issuecomment-2837404350

From duke at openjdk.org  Tue Apr 29 04:19:55 2025
From: duke at openjdk.org (simon)
Date: Tue, 29 Apr 2025 04:19:55 GMT
Subject: Integrated: 8350542: Optional.orElseThrow(Supplier) does not specify
 behavior when supplier returns null
In-Reply-To: 
References: 
Message-ID: 

On Tue, 4 Mar 2025 16:34:19 GMT, simon  wrote:

> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of another possible cause of a NullPointerException - when the exception supplying function returns a null result.
> ---------
> ### Progress
> - [x] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change requires CSR request [JDK-8354953](https://bugs.openjdk.org/browse/JDK-8354953) to be approved
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> ### Error
>  ?? The pull request body must not be empty.
> 
> 
> 
> ### Reviewing
> 
Using git
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk.git pull/23905/head:pull/23905` \
> `$ git checkout pull/23905`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/23905` \
> `$ git pull https://git.openjdk.org/jdk.git pull/23905/head`
> 
> 

> 
Using Skara CLI tools
> 
> Checkout this PR locally: \
> `$ git pr checkout 23905`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 23905`
> 
> 

> 
Using diff file
> 
> Download this PR as a diff file: \
> https://git.openjdk.org/jdk/pull/23905.diff
> 
> 


This pull request has now been integrated.

Changeset: 44374a57
Author:    Gustavo Simon 
Committer: Christoph Langer 
URL:       https://git.openjdk.org/jdk/commit/44374a572096fc98b390ab2cb9063d832e110020
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8350542: Optional.orElseThrow(Supplier) does not specify behavior when supplier returns null

Reviewed-by: liach, clanger

-------------

PR: https://git.openjdk.org/jdk/pull/23905

From alanb at openjdk.org  Tue Apr 29 05:41:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Apr 2025 05:41:47 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value [v4]
In-Reply-To: 
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
 
Message-ID: 

On Mon, 28 Apr 2025 16:45:01 GMT, Brian Burkhalter  wrote:

>> Use the `@requires` tag instead of obtaining the operating system name from the `os.name` property and then exiting if the test is not run on that operating system.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8355444: Add comment tag tp ManyFiles

test/jdk/java/io/FileOutputStream/ManyFiles.java line 33:

> 31:  * Windows capability it is much simpler to only run it
> 32:  * on that platform.
> 33:  * @requires (os.family != "linux")

I think this comment should be replaced with a clear summary as to why three is a requires. No need to mention Solaris.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24860#discussion_r2065531220

From liach at openjdk.org  Tue Apr 29 06:14:33 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 06:14:33 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v9]
In-Reply-To: 
References: 
Message-ID: 

> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
> 
> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
> 
> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
> 
> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Try to simplify the model - use the finish of computeValue

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24043/files
  - new: https://git.openjdk.org/jdk/pull/24043/files/8d0f26d3..5ac82864

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=07-08

  Stats: 116 lines in 1 file changed: 21 ins; 48 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/24043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24043/head:pull/24043

PR: https://git.openjdk.org/jdk/pull/24043

From ihse at openjdk.org  Tue Apr 29 06:46:51 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Apr 2025 06:46:51 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
References: 
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
Message-ID: 

On Wed, 23 Apr 2025 00:56:18 GMT, Jiangli Zhou  wrote:

>> Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
>> 
>> `NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.
>> 
>> In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
>  - Address henryjen@ comment:
>    - Remove '#include '.

This was news to me. I'm thinking about what this means in terms of the static build, where all native JDK libraries are "loaded" as soon as the application starts executing. Do we have native libraries in the JDK that are not loaded by the boot loader? If so, have we introduced some corner case effects by marking them with the static JNI symbol? ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2837654312

From pminborg at openjdk.org  Tue Apr 29 07:14:00 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 29 Apr 2025 07:14:00 GMT
Subject: RFR: 8347814: Make all imports consistent in the FFM API tests and
 benchmarks
In-Reply-To: <5KNH2AAZ_KnLt2xRMfHFFNmJ8zf0p6n-arS-XSq5jm8=.3b36aafe-b403-4bf4-89e3-548829d46673@github.com>
References: <5KNH2AAZ_KnLt2xRMfHFFNmJ8zf0p6n-arS-XSq5jm8=.3b36aafe-b403-4bf4-89e3-548829d46673@github.com>
Message-ID: 

On Wed, 19 Feb 2025 09:22:09 GMT, Per Minborg  wrote:

> This PR proposes to make all imports consistent in the FFM API tests and benchmarks.
> 
> This is a follow-up PR from https://github.com/openjdk/jdk/pull/22827
> 
> Passes tier1-3

In the end, this didn't make the bar in terms of cost/benefit.  For example, backporting might be impacted.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23689#issuecomment-2837727676

From aph at openjdk.org  Tue Apr 29 07:17:26 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 29 Apr 2025 07:17:26 GMT
Subject: RFR: 8355720: Implement JEP 506: Scoped Values
Message-ID: 

Propose to finalize scoped values.
The only functional change is that the orElse() method no longer accepts a null argument.

-------------

Commit messages:
 - 8355720: Implement JEP 506: Scoped Values
 - Implement JEP 506: Scoped Values

Changes: https://git.openjdk.org/jdk/pull/24923/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24923&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355720
  Stats: 11 lines in 2 files changed: 1 ins; 5 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24923/head:pull/24923

PR: https://git.openjdk.org/jdk/pull/24923

From liach at openjdk.org  Tue Apr 29 07:17:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 07:17:26 GMT
Subject: RFR: 8355720: Implement JEP 506: Scoped Values
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Apr 2025 14:32:04 GMT, Andrew Haley  wrote:

> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a null argument.

Nit: is the no-arg constructor of `Snapshot` supposed to be `private` instead?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2835642166

From alanb at openjdk.org  Tue Apr 29 07:17:26 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Apr 2025 07:17:26 GMT
Subject: RFR: 8355720: Implement JEP 506: Scoped Values
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Apr 2025 14:32:04 GMT, Andrew Haley  wrote:

> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a null argument.

@theRealAph There are test updates in the loom repo that will also need to be included in this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2835660215

From duke at openjdk.org  Tue Apr 29 07:17:26 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 29 Apr 2025 07:17:26 GMT
Subject: RFR: 8355720: Implement JEP 506: Scoped Values
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Apr 2025 14:32:04 GMT, Andrew Haley  wrote:

> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a null argument.

src/java.base/share/classes/java/lang/ScopedValue.java line 614:

> 612:      */
> 613:     public T orElse(T other) {
> 614:         Objects.requireNonNull(other);

Why?was this change made?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24923#discussion_r2064127351

From liach at openjdk.org  Tue Apr 29 07:17:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 07:17:26 GMT
Subject: RFR: 8355720: Implement JEP 506: Scoped Values
In-Reply-To: 
References: 
 
Message-ID: <4SK0_MOV5_v7ILYjN33sK4jAGhvUuIVMjwNOxTU1Luo=.695a77c0-3933-4205-aaad-b31e8e27f66e@github.com>

On Mon, 28 Apr 2025 17:15:34 GMT, ExE Boss  wrote:

>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a null argument.
>
> src/java.base/share/classes/java/lang/ScopedValue.java line 614:
> 
>> 612:      */
>> 613:     public T orElse(T other) {
>> 614:         Objects.requireNonNull(other);
> 
> Why?was this change made?

> The only functional change is that the orElse() method no longer accepts a null argument.

See https://mail.openjdk.org/pipermail/loom-dev/2025-April/007470.html for some history.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24923#discussion_r2064142621

From serb at openjdk.org  Tue Apr 29 07:29:54 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 29 Apr 2025 07:29:54 GMT
Subject: RFR: 8347814: Make all imports consistent in the FFM API tests and
 benchmarks
In-Reply-To: 
References: <5KNH2AAZ_KnLt2xRMfHFFNmJ8zf0p6n-arS-XSq5jm8=.3b36aafe-b403-4bf4-89e3-548829d46673@github.com>
 
Message-ID: 

On Tue, 29 Apr 2025 07:11:30 GMT, Per Minborg  wrote:

> In the end, this didn't make the bar in terms of cost/benefit. For example, backporting might be impacted.

The first LTS release to include this API will be 25, correct? It would be best to clean this up in advance, as backporting to versions 22, 23, or 24 is unlikely - just a thought.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23689#issuecomment-2837778394

From tschatzl at openjdk.org  Tue Apr 29 07:39:22 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 29 Apr 2025 07:39:22 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v36]
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 52 commits:

 - Merge branch 'master' into card-table-as-dcq-merge
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review (part 2 - yield duration changes)
 - * ayang review (part 1)
 - * indentation fix
 - * remove support for 32 bit x86 in the barrier generation code, following latest changes from @shade
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * fixes after merge related to 32 bit x86 removal
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review: revising young gen length
   * robcasloz review: various minor refactorings
 - ... and 42 more: https://git.openjdk.org/jdk/compare/44374a57...51dfbe54

-------------

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=35
  Stats: 7102 lines in 110 files changed: 2583 ins; 3598 del; 921 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 aph at openjdk.org  Tue Apr 29 07:41:28 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 29 Apr 2025 07:41:28 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v2]
In-Reply-To: 
References: 
Message-ID: 

> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a null argument.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  ScopedValue::orElse() does not accept null as an argument.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24923/files
  - new: https://git.openjdk.org/jdk/pull/24923/files/b4d77672..00ded12f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24923&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24923&range=00-01

  Stats: 5 lines in 1 file changed: 2 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24923/head:pull/24923

PR: https://git.openjdk.org/jdk/pull/24923

From alanb at openjdk.org  Tue Apr 29 07:46:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Apr 2025 07:46:50 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v2]
In-Reply-To: 
References: 
 
Message-ID: <8dDns3DRU5ZT40Su5HTfD69dPLFIEj8RAxe2SSzDgMw=.1511fb22-80eb-4d38-b5f5-7d6d3671cfe6@github.com>

On Tue, 29 Apr 2025 07:41:28 GMT, Andrew Haley  wrote:

>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a null argument.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ScopedValue::orElse() does not accept null as an argument.

src/java.base/share/classes/java/lang/ScopedValue.java line 314:

> 312:      * @since 21
> 313:      */
> 314:     @PreviewFeature(feature = PreviewFeature.Feature.SCOPED_VALUES)

The @since need to be updated for all APIs that are proposed to be permanent. This means that Carrier and CallableOp need their @since updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24923#discussion_r2065716300

From aph at openjdk.org  Tue Apr 29 07:54:23 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 29 Apr 2025 07:54:23 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v3]
In-Reply-To: 
References: 
Message-ID: 

> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a null argument.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Since when?

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24923/files
  - new: https://git.openjdk.org/jdk/pull/24923/files/00ded12f..d3f2ff1f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24923&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24923&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24923/head:pull/24923

PR: https://git.openjdk.org/jdk/pull/24923

From alanb at openjdk.org  Tue Apr 29 07:57:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Apr 2025 07:57:53 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: 
References: 
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
 
Message-ID: <6I7C4_Tn-A5rW6VOjZreazlljB4JYH4_2KQpH2oAgy8=.ef149511-c081-4503-9af4-80dc397afb3e@github.com>

On Tue, 29 Apr 2025 06:43:59 GMT, Magnus Ihse Bursie  wrote:

> Do we have native libraries in the JDK that are not loaded by the boot loader? 

There are few, e.g. java.security.jgss, jdk.security.auth and jdk.crypto.cryptoki are mapped to the platform class loader, and jdk.attach mapped to the application class loader.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2837849469

From alanb at openjdk.org  Tue Apr 29 07:59:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Apr 2025 07:59:47 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 07:54:23 GMT, Andrew Haley  wrote:

>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a null argument.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Since when?

src/java.base/share/classes/java/lang/ScopedValue.java line 412:

> 410:          * @throws StructureViolationException if a structure violation is detected
> 411:          * @throws X if {@code op} completes with an exception
> 412:          * @since 25

The `@since` on the method be dropped once Carrier is bumped to 25.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24923#discussion_r2065735184

From pminborg at openjdk.org  Tue Apr 29 08:15:15 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 29 Apr 2025 08:15:15 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v78]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Fri, 25 Apr 2025 09:17:13 GMT, Luca Kellermann  wrote:

>> `setOrThrow` might be invoked several times. If the first invocation failed because the supplier threw and then the second invocation (with the same supplier) succeded (because there was some state that changed), we have this situation.
>
> `orElseSet` is the method taking a supplier, `setOrThrow` doesn't.

Ahh. I'm sorry for misreading this. The docs should say `orElseSet` rather than `orElseThrow`. Again, we will fix this in a follow-up PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2065757267

From thomas.stuefe at gmail.com  Tue Apr 29 09:04:18 2025
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 29 Apr 2025 11:04:18 +0200
Subject: Runtime.exec and SIGPIPE + SIG_IGN
Message-ID: 

Hi,

I would like to gauge opinions on whether the following scenario is a bug
to fix or whether to accept it as standard behavior.

---

A customer has the following problem:

- The JVM invokes a third-party JNI library that sets the signal
disposition of SIGPIPE to SIG_IGN (Boo! in this case, it is the FIPS nspr
library, which does this unconditionally.)
- The JVM then spawns child processes
- All child processes now ignore SIGPIPE, which leads to failures in
automation scripts

I was surprised. I always assumed the signal disposition of all signals
would be reset to SIG_DFL when exec'ing. However, seems I was wrong when it
came to SIG_IGN. Posix documents for execve() states [1]:

1) " Signals set to the default action (SIG_DFL) in the calling process
image shall be set to the default action in the new process image."

and

2) "Except for SIGCHLD, signals set to be ignored (SIG_IGN) by the calling
process image shall be set to be ignored by the new process image."

and

3) "Signals set to be caught by the calling process image shall be set to
the default action in the new process image (see **
)."

(2) and (3) are the interesting parts. (2) means that if the parent process
ignores SIGPIPE, child processes will also ignore SIGPIPE. (3) means that
if the parent process has a custom handler installed for SIGPIPE, child
processes will be started with SIG_DFL (default action) for SIGPIPE. The
default action for SIGPIPE is "terminate process".
The libjvm handles SIGPIPE. We install our `javaSignalHandler`. We do this
to eat up and ignore SIGPIPE. That we "manually" ignore the signal beside
the point here - what counts is that we set a custom signal handler for
SIGPIPE. Therefore, on execve, we behave according to rule (3) and start
the child with SIG_DFL as SIGPIPE disposition. As it should be.

If third-party code sets the handler to SIG_IGN as in this example, exeve
will behave according to rule (2) and the child will start with SIG_IGN as
SIGPIPE disposition.

The libjig can be used to workaround this scenario, but I wonder if that is
more of an accident. The libjsig.so will preserve the JVM's SIGPIPE handler
even if third-party code attempts to set it to SIG_IGN. That means that
exeve still behaves according to rule (2): sets child's SIGPIPE disposition
to SIG_DFL.

----

But I wonder whether this should not be considered a bug to fix regardless
of the jsig.so workaround? In jspawnhelper, we clean the environment from
various effects when exec'ing; among other things, we reset the signal
block mask for the process. The "ignore" state of processes could be
considered along the same line. We could reset all signal handlers to
SIG_DFL before execing the child.

I know that this area is super-tricky and problems are notoriously
difficult to analyze; we should therefore be extremely careful not to break
downward compatibility. Still, what do people think? Should be fix this in
jspawnhelper?

Thanks, Thomas

(cc'ing Roger)

[1] https://pubs.opengroup.org/onlinepubs/009695399/functions/exec.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From alanb at openjdk.org  Tue Apr 29 09:48:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Apr 2025 09:48:50 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 07:54:23 GMT, Andrew Haley  wrote:

>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a null argument.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Since when?

test/jdk/java/lang/ScopedValue/ScopedValueAPI.java line 424:

> 422:         assertThrows(NullPointerException.class, () -> carrier.run(null));
> 423:         assertThrows(NullPointerException.class, () -> carrier.call(null));
> 424:         assertThrows(NullPointerException.class, () -> carrier.run(() -> name.orElse(null)));

Thanks for brining in the update to ScopedValueAPI test. The `@enablePreview` can be removed from the test description of this test, and the others in this directory that don't use STS.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24923#discussion_r2065949496

From mcimadamore at openjdk.org  Tue Apr 29 10:16:49 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 29 Apr 2025 10:16:49 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Apr 2025 13:26:30 GMT, Jan Lahoda  wrote:

>> This is a patch to finalize the module imports feature. Please see:
>> https://bugs.openjdk.org/browse/JDK-8344700
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'master' into JDK-8344708
>  - Adjusting ToolProviderTest to the updated persistence handling.
>  - Merge branch 'master' into JDK-8344708
>  - Reflecting review feedback: cleanup formatting in ModuleInfo.
>  - Reflecting review feedback - avoiding hardcoded constants.
>  - Fixing test.
>  - Cleanup, fixing tests.
>  - Adjusting JShell defaults.
>  - Fixing tests.
>  - Cleanup - updated specification will permit requires transitive java.base; for all classfile versions; java.se no longer participates in preview.
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/1f228e55...da39d0ef

src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Startup.java line 345:

> 343:         boolean hasModuleImports = source == null ||
> 344:                                    Feature.MODULE_IMPORTS.allowedInSource(source);
> 345:         int idx = preview ? 2 : !hasModuleImports ? 1 : 0;

It feels like this would be cleaner with an if/else if/else? I'm also not a big fan of hardcoded constants into an array. Maybe this code can benefit from stable values (when they are integrated).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23801#discussion_r2065991188

From mcimadamore at openjdk.org  Tue Apr 29 10:16:49 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 29 Apr 2025 10:16:49 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 29 Apr 2025 10:12:07 GMT, Maurizio Cimadamore  wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - Merge branch 'master' into JDK-8344708
>>  - Adjusting ToolProviderTest to the updated persistence handling.
>>  - Merge branch 'master' into JDK-8344708
>>  - Reflecting review feedback: cleanup formatting in ModuleInfo.
>>  - Reflecting review feedback - avoiding hardcoded constants.
>>  - Fixing test.
>>  - Cleanup, fixing tests.
>>  - Adjusting JShell defaults.
>>  - Fixing tests.
>>  - Cleanup - updated specification will permit requires transitive java.base; for all classfile versions; java.se no longer participates in preview.
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/1f228e55...da39d0ef
>
> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Startup.java line 345:
> 
>> 343:         boolean hasModuleImports = source == null ||
>> 344:                                    Feature.MODULE_IMPORTS.allowedInSource(source);
>> 345:         int idx = preview ? 2 : !hasModuleImports ? 1 : 0;
> 
> It feels like this would be cleaner with an if/else if/else? I'm also not a big fan of hardcoded constants into an array. Maybe this code can benefit from stable values (when they are integrated).

(in the interim, maybe using an enum with the possible values, instead of indices, and then turning `defaultStartup` into an EnumMap might make the code slightly clearer?)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23801#discussion_r2065993361

From epeter at openjdk.org  Tue Apr 29 10:24:47 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 29 Apr 2025 10:24:47 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v3]
In-Reply-To: 
References: 
 
Message-ID: <1Qo4pB9I7Ok4ntXSE-KkE0sv-Tp5EVCWriWnjcf2iEE=.a7e28640-85df-436a-9c82-3c067cc88dee@github.com>

On Fri, 25 Apr 2025 07:24:15 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 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:
> 
>  - Addressed some review comments
>    
>    1. Call VectorNode::Ideal() only once in XorVNode::Ideal.
>    2. Improve code comments.
>  - Merge branch 'master' into JDK-8354242
>  - Merge branch 'master' into JDK-8354242
>  - 8354242: VectorAPI: combine vector not operation with compare
>    
>    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	2...

Yes, this discussion is down to `requires` vs `applyIf`. This is my argument for `applyIf`, quoted from above, I have not yet seen an argument against it:

>  If you use @require, then the person does not realize there is a test AND the test is not run. If you use applyIf, the person does not realize there is a test, but it is run at least for result verifiation - and then the person MIGHT realize if the test catches a wrong result / crash.

In my understanding, `requires` should only be used if the test really **requires** a certain platform or feature. That can be because some flags are only available under certain platforms for example. But for IR tests, we should try to always use `applyIf`, because it allows testing on other platforms.

Actually, I filed this RFE a while ago: https://bugs.openjdk.org/browse/JDK-8310891
We should try to move as many tests from using `requires` to `applyIf`, so that we have an increased test coverage.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-2838240704

From mcimadamore at openjdk.org  Tue Apr 29 10:25:49 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 29 Apr 2025 10:25:49 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Apr 2025 13:26:30 GMT, Jan Lahoda  wrote:

>> This is a patch to finalize the module imports feature. Please see:
>> https://bugs.openjdk.org/browse/JDK-8344700
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'master' into JDK-8344708
>  - Adjusting ToolProviderTest to the updated persistence handling.
>  - Merge branch 'master' into JDK-8344708
>  - Reflecting review feedback: cleanup formatting in ModuleInfo.
>  - Reflecting review feedback - avoiding hardcoded constants.
>  - Fixing test.
>  - Cleanup, fixing tests.
>  - Adjusting JShell defaults.
>  - Fixing tests.
>  - Cleanup - updated specification will permit requires transitive java.base; for all classfile versions; java.se no longer participates in preview.
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/1f228e55...da39d0ef

src/jdk.jshell/share/classes/jdk/jshell/SnippetMaps.java line 197:

> 195:             return full.substring(pkg.length() + 1);
> 196:         }
> 197:         Stream mods = importSnippets()

Should this variable be called `mods` ? AFAIU, it lists all the packages exported by a module.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23801#discussion_r2066007798

From duke at openjdk.org  Tue Apr 29 10:54:33 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Apr 2025 10:54:33 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v41]
In-Reply-To: 
References: 
Message-ID: 

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Decrease exponents in tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/51272bc6..70da95cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=40
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=39-40

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From duke at openjdk.org  Tue Apr 29 11:03:48 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Apr 2025 11:03:48 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v40]
In-Reply-To: <_kZNEz6jIVzlHMKNK0nPnZdVdAfI1l_X4eRrRJH62i8=.61eedea0-bb33-419d-8391-b5ae2194e6ed@github.com>
References: 
 
 <_kZNEz6jIVzlHMKNK0nPnZdVdAfI1l_X4eRrRJH62i8=.61eedea0-bb33-419d-8391-b5ae2194e6ed@github.com>
Message-ID: 

On Mon, 28 Apr 2025 17:06:55 GMT, Raffaello Giulietti  wrote:

> Can you show the benchmark results before/after, perhaps specifying the characteristics of your machine (CPU make/model, RAM, OS)?

CPU: Intel Core i3 7100U @ 2.40GHz
RAM: 8,00GB Dual-Channel DDR4 @ 1063MHz
OS: Kali Linux 2025.1a-amd64 (virtual machine on Windows)

With the default JVM on Kali Linux, I get this results:


JMH version: 1.37
VM version: JDK 21.0.7-ea, OpenJDK 64-Bit Server VM, 21.0.7-ea+8-Debian-1

Benchmark                                   Mode  Cnt            Score             Error   Units
BigIntegerPow.testPowL                      avgt    3  18947869090.667 ?  3911381786.675   ns/op
BigIntegerPow.testPowL:gc.alloc.rate        avgt    3         1969.373 ?         409.941  MB/sec
BigIntegerPow.testPowL:gc.alloc.rate.norm   avgt    3  39130645992.000 ?         583.799    B/op
BigIntegerPow.testPowL:gc.count             avgt    3          751.000                    counts
BigIntegerPow.testPowL:gc.time              avgt    3         1459.000                        ms
BigIntegerPow.testPowM                      avgt    3  19118357966.000 ?  3469381107.647   ns/op
BigIntegerPow.testPowM:gc.alloc.rate        avgt    3         1949.412 ?         353.047  MB/sec
BigIntegerPow.testPowM:gc.alloc.rate.norm   avgt    3  39080806429.333 ?         337.057    B/op
BigIntegerPow.testPowM:gc.count             avgt    3          721.000                    counts
BigIntegerPow.testPowM:gc.time              avgt    3         1384.000                        ms
BigIntegerPow.testPowS                      avgt    3  19440511008.000 ? 28974697236.522   ns/op
BigIntegerPow.testPowS:gc.alloc.rate        avgt    3         1836.681 ?        2636.321  MB/sec
BigIntegerPow.testPowS:gc.alloc.rate.norm   avgt    3  37281212394.667 ?         337.057    B/op
BigIntegerPow.testPowS:gc.count             avgt    3          744.000                    counts
BigIntegerPow.testPowS:gc.time              avgt    3         1491.000                        ms
BigIntegerPow.testPowXL                     avgt    3  18702202580.667 ?  3764367371.343   ns/op
BigIntegerPow.testPowXL:gc.alloc.rate       avgt    3         2001.545 ?         402.444  MB/sec
BigIntegerPow.testPowXL:gc.alloc.rate.norm  avgt    3  39249581138.667 ?         337.057    B/op
BigIntegerPow.testPowXL:gc.count            avgt    3          763.000                    counts
BigIntegerPow.testPowXL:gc.time             avgt    3         1398.000                        ms
BigIntegerPow.testPowXS                     avgt    3  15613228655.667 ?  2307582100.089   ns/op
BigIntegerPow.testPowXS:gc.alloc.rate       avgt    3         1807.160 ?         266.932  MB/sec
BigIntegerPow.testPowXS:gc.alloc.rate.norm  avgt    3  29586699256.000 ?         583.799    B/op
BigIntegerPow.testPowXS:gc.count            avgt    3          525.000                    counts
BigIntegerPow.testPowXS:gc.time             avgt    3         1006.000                        ms


Instead, when I try to run the tests with OpenJDK 25, unfortunately I get this Exception:


Exception in thread "main" java.lang.RuntimeException: ERROR: Unable to find the resource: /META-INF/BenchmarkList
        at org.openjdk.jmh.runner.AbstractResourceReader.getReaders(AbstractResourceReader.java:98)
        at org.openjdk.jmh.runner.BenchmarkList.find(BenchmarkList.java:124)
        at org.openjdk.jmh.runner.Runner.internalRun(Runner.java:252)
        at org.openjdk.jmh.runner.Runner.run(Runner.java:208)
        at org.openjdk.jmh.Main.main(Main.java:71)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2838326374

From duke at openjdk.org  Tue Apr 29 11:10:23 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Apr 2025 11:10:23 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v42]
In-Reply-To: 
References: 
Message-ID: 

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Update test parameters

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/70da95cb..d85a634e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=41
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=40-41

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From duke at openjdk.org  Tue Apr 29 11:39:00 2025
From: duke at openjdk.org (Oliver Kopp)
Date: Tue, 29 Apr 2025 11:39:00 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev  wrote:

> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
> - This change is for macOS only.
> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.

Google directed me here. We updated from JDK23 to JDK24

We have

    --app-content buildres/mac/jabrefHost.py

JDK23: Without any issue

JDK24: 


"codesign" failed and additional application content was supplied via the "--app-content" parameter. Probably the additional content broke the integrity of the application bundle and caused the failure. Ensure content supplied via the "--app-content" parameter does not break the integrity of the application bundle, or add it in the post-processing step.
[10:08:52.963] Running /usr/bin/xcrun
[10:08:52.973] Command [PID: 9939]:
    /usr/bin/xcrun --help
[10:08:52.973] Output:
    Usage: xcrun [options]  ... arguments ...
    
    Find and execute the named command line tool from the active developer
    directory.
    
    The active developer directory can be set using `xcode-select`, or via the
    DEVELOPER_DIR environment variable. See the xcrun and xcode-select manual
    pages for more information.
    
    Options:
      -h, --help                  show this help message and exit
      --version                   show the xcrun version
      -v, --verbose               show verbose logging output
      --sdk             find the tool for the given SDK name
      --toolchain           find the tool for the given toolchain
      -l, --log                   show commands to be executed (with --run)
      -f, --find                  only find and print the tool path
      -r, --run                   find and execute the tool (the default behavior)
      -n, --no-cache              do not use the lookup cache
      -k, --kill-cache            invalidate all existing cache entries
      --show-sdk-path             show selected SDK install path
      --show-sdk-version          show selected SDK version
      --show-sdk-build-version    show selected SDK build version
      --show-sdk-platform-path    show selected SDK platform path
      --show-sdk-platform-version show selected SDK platform version
[10:08:52.974] Returned: 0

Error: "codesign" failed with following output:
/var/folders/gn/rldh9pd93qg48089gvgb1gb80000gn/T/jdk.jpackage3854937683320166432/images/image-16322408788641963111/JabRef.app: replacing existing signature
/var/folders/gn/rldh9pd93qg48089gvgb1gb80000gn/T/jdk.jpackage3854937683320166432/images/image-16322408788641963111/JabRef.app: code object is not signed at all
In subcomponent: /private/var/folders/gn/rldh9pd93qg48089gvgb1gb80000gn/T/jdk.jpackage3854937683320166432/images/image-16322408788641963111/JabRef.app/Contents/***Host.py


Full example: at https://github.com/JabRef/jabref/pull/13032

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2838481133

From kbarrett at openjdk.org  Tue Apr 29 11:50:45 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 29 Apr 2025 11:50:45 GMT
Subject: RFR: 8355632: WhiteBox.waitForReferenceProcessing() fails assert
 for return type [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Apr 2025 19:21:05 GMT, Brent Christian  wrote:

>> The newly-added `WhiteBox.waitForReferenceProcessing()` (see [8305186](https://bugs.openjdk.org/browse/JDK-8305186)) always fails with assertions enabled.
>> I've updated the assertion, and also added the test I used locally to test the new method (just not with assertions enabled, apparently.)
>
> Brent Christian has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - move test
>  - rename test class
>  - enable assertions on test itself
>  - use boolean.class

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24892#pullrequestreview-2803110349

From pminborg at openjdk.org  Tue Apr 29 12:33:34 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 29 Apr 2025 12:33:34 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v6]
In-Reply-To: 
References: 
Message-ID: 

> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
> 
> 
> Here are some benchmarks that ran on a platform thread and virtual threads respectively (M1 Mac):
> 
> 
> Benchmark                                                  Mode  Cnt   Score   Error  Units
> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.330 ? 0.820  ns/op
> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.257 ? 0.117  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  41.415 ? 1.013  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.720 ? 0.463  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.636 ? 0.182  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.234 ? 0.156  ns/op
> CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.918 ? 0.487  ns/op
> CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   4.946 ? 0.089  ns/op
> CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.280 ? 1.128  ns/op
> CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  21.809 ? 0.413  ns/op
> CaptureStateUtilBench.tlAllocationFail                     avgt   30  24.422 ? 0.673  ns/op
> CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   5.182 ? 0.152  ns/op
> 
> 
> Adapted system call:
> 
>         return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool
> ```        
> Explicit allocation:
> 
>         try (var arena = Arena.ofConfined()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
>         }
> ```        
> Thread Local allocation:
> 
>         try (var arena = POOLS.take()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool
>         }
> ```        
> The adapted system call exhibits a ~4x performance improvement over the existing "explicit allocation" scheme for the happy path on platform threads. ...

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add hashCode/equals to record to improve startup time

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23765/files
  - new: https://git.openjdk.org/jdk/pull/23765/files/c0e46d30..174da716

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23765&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23765&range=04-05

  Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23765.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23765/head:pull/23765

PR: https://git.openjdk.org/jdk/pull/23765

From jlahoda at openjdk.org  Tue Apr 29 12:34:00 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 29 Apr 2025 12:34:00 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v7]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 29 Apr 2025 10:13:39 GMT, Maurizio Cimadamore  wrote:

>> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Startup.java line 345:
>> 
>>> 343:         boolean hasModuleImports = source == null ||
>>> 344:                                    Feature.MODULE_IMPORTS.allowedInSource(source);
>>> 345:         int idx = preview ? 2 : !hasModuleImports ? 1 : 0;
>> 
>> It feels like this would be cleaner with an if/else if/else? I'm also not a big fan of hardcoded constants into an array. Maybe this code can benefit from stable values (when they are integrated).
>
> (in the interim, maybe using an enum with the possible values, instead of indices, and then turning `defaultStartup` into an EnumMap might make the code slightly clearer?)

Thanks for the comments, attempted to fix here:
https://github.com/openjdk/jdk/pull/23801/commits/4f9575564c3761b251288c3dec0132cbe0a16139

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23801#discussion_r2066219206

From jlahoda at openjdk.org  Tue Apr 29 12:33:59 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 29 Apr 2025 12:33:59 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v8]
In-Reply-To: 
References: 
Message-ID: 

> This is a patch to finalize the module imports feature. Please see:
> https://bugs.openjdk.org/browse/JDK-8344700

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23801/files
  - new: https://git.openjdk.org/jdk/pull/23801/files/da39d0ef..4f957556

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23801&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23801&range=06-07

  Stats: 70 lines in 2 files changed: 35 ins; 17 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/23801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23801/head:pull/23801

PR: https://git.openjdk.org/jdk/pull/23801

From jlahoda at openjdk.org  Tue Apr 29 12:34:02 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 29 Apr 2025 12:34:02 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 29 Apr 2025 10:23:26 GMT, Maurizio Cimadamore  wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - Merge branch 'master' into JDK-8344708
>>  - Adjusting ToolProviderTest to the updated persistence handling.
>>  - Merge branch 'master' into JDK-8344708
>>  - Reflecting review feedback: cleanup formatting in ModuleInfo.
>>  - Reflecting review feedback - avoiding hardcoded constants.
>>  - Fixing test.
>>  - Cleanup, fixing tests.
>>  - Adjusting JShell defaults.
>>  - Fixing tests.
>>  - Cleanup - updated specification will permit requires transitive java.base; for all classfile versions; java.se no longer participates in preview.
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/1f228e55...da39d0ef
>
> src/jdk.jshell/share/classes/jdk/jshell/SnippetMaps.java line 197:
> 
>> 195:             return full.substring(pkg.length() + 1);
>> 196:         }
>> 197:         Stream mods = importSnippets()
> 
> Should this variable be called `mods` ? AFAIU, it lists all the packages exported by a module.

Thanks, attempted to improve here:
https://github.com/openjdk/jdk/pull/23801/commits/4f9575564c3761b251288c3dec0132cbe0a16139

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23801#discussion_r2066219542

From duke at openjdk.org  Tue Apr 29 13:10:19 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Tue, 29 Apr 2025 13:10:19 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
Message-ID: 

8352926: New test TestDockerMemoryMetricsSubgroup.java fails

-------------

Commit messages:
 - update comment
 - 8352926: New test TestDockerMemoryMetricsSubgroup.java fails

Changes: https://git.openjdk.org/jdk/pull/24948/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352926
  Stats: 157 lines in 2 files changed: 157 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24948.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24948/head:pull/24948

PR: https://git.openjdk.org/jdk/pull/24948

From heidinga at openjdk.org  Tue Apr 29 13:28:49 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 29 Apr 2025 13:28:49 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v4]
In-Reply-To: 
References: 
 
 
 
 <2Gy-nNmowCMbzeMWCW2HJasKpxPfTgFwOPUScNd-ywg=.d8d8c09a-e9d9-44a1-b1f0-b4f45047f719@github.com>
 
Message-ID: 

On Mon, 28 Apr 2025 21:08:10 GMT, Ioi Lam  wrote:

>> We're creating a set of hooks - right now, there is one in MT - that are called by the VM at the appropriate time during the assembly phase to massage the class's state before we write the AOTCache out.
>> 
>> Conceptually any class could have a `prepareForAOTCache` method that would act as a front door for the VM to know how to set up its state.  
>> 
>> Right now we have a hard coded list of one class - MT - that we call `prepareForAOTCache` on.  Another way to implement this would be to loop through all classes that AOTCache candidates and call their `prepareForAOTCache` method (fi they have one).
>> 
>> If we expand this beyond MT, how does a reader of the code know which classes have VM call-in points and which don't?
>> 
>> (I'll mention here I missed the static modifier was only on MT which changes the argument a little but I still think different names would be clearer to diffierntiate between what the VM is expected to call and what may happen to the instances)
>
> How about `MethodType::assemblySetup()` for the entry point? This kind of mirrors the `runtimeSetup()` entry points that are called after the AOT cache is loaded. In the future, we can use annotation to mark such entry points to avoid explicit calls from the JVM.

That's a great choice!  It makes it clear when the method is run, parallels `runtimeSetup`, and differentiates it from the instance method helpers.  Thanks Ioi for working thru this with me!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2066407185

From duke at openjdk.org  Tue Apr 29 13:31:48 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Apr 2025 13:31:48 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v40]
In-Reply-To: <_kZNEz6jIVzlHMKNK0nPnZdVdAfI1l_X4eRrRJH62i8=.61eedea0-bb33-419d-8391-b5ae2194e6ed@github.com>
References: 
 
 <_kZNEz6jIVzlHMKNK0nPnZdVdAfI1l_X4eRrRJH62i8=.61eedea0-bb33-419d-8391-b5ae2194e6ed@github.com>
Message-ID: 

On Mon, 28 Apr 2025 17:06:55 GMT, Raffaello Giulietti  wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added tests for memory consumption
>
> Can you show the benchmark results before/after, perhaps specifying the characteristics of your machine (CPU make/model, RAM, OS)?

@rgiulietti As you can see, there is a significant saving in both execution time and memory consumption.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2838923045

From asemenyuk at openjdk.org  Tue Apr 29 13:36:59 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 29 Apr 2025 13:36:59 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 11:35:29 GMT, Oliver Kopp  wrote:

>> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
>> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
>> - This change is for macOS only.
>> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.
>
> Google directed me here. We updated from JDK23 to JDK24
> 
> We have
> 
>     --app-content buildres/mac/jabrefHost.py
> 
> JDK23: Without any issue
> 
> JDK24: 
> 
> 
> "codesign" failed and additional application content was supplied via the "--app-content" parameter. Probably the additional content broke the integrity of the application bundle and caused the failure. Ensure content supplied via the "--app-content" parameter does not break the integrity of the application bundle, or add it in the post-processing step.
> [10:08:52.963] Running /usr/bin/xcrun
> [10:08:52.973] Command [PID: 9939]:
>     /usr/bin/xcrun --help
> [10:08:52.973] Output:
>     Usage: xcrun [options]  ... arguments ...
>     
>     Find and execute the named command line tool from the active developer
>     directory.
>     
>     The active developer directory can be set using `xcode-select`, or via the
>     DEVELOPER_DIR environment variable. See the xcrun and xcode-select manual
>     pages for more information.
>     
>     Options:
>       -h, --help                  show this help message and exit
>       --version                   show the xcrun version
>       -v, --verbose               show verbose logging output
>       --sdk             find the tool for the given SDK name
>       --toolchain           find the tool for the given toolchain
>       -l, --log                   show commands to be executed (with --run)
>       -f, --find                  only find and print the tool path
>       -r, --run                   find and execute the tool (the default behavior)
>       -n, --no-cache              do not use the lookup cache
>       -k, --kill-cache            invalidate all existing cache entries
>       --show-sdk-path             show selected SDK install path
>       --show-sdk-version          show selected SDK version
>       --show-sdk-build-version    show selected SDK build version
>       --show-sdk-platform-path    show selected SDK platform path
>       --show-sdk-platform-version show selected SDK platform version
> [10:08:52.974] Returned: 0
> 
> Error: "codesign" failed with following output:
> /var/folders/gn/rldh9pd93qg48089gvgb1gb80000gn/T/jdk.jpackage3854937683320166432/images/image-16322408788641963111/JabRef.app: replacing existing signature
> /var/folders/gn/rldh9pd93qg48089gvgb1gb80000gn/T/jdk.jpackage3854937683320166432/images/image-16322408788641963111/JabRef.app: code object is not signed at all
> In subcomponent: /private/var/folders/gn/rldh9pd93qg48089gvgb1gb80000gn/T/jdk.jpackage3854937683320166...

@koppor,

We had a very similar issue in one of jpackage tests when we tried to copy random files in the "Contents" directory. See a comment at [AppContentTest.java#L62](https://github.com/openjdk/jdk/blob/edf8ce8db10521037045115f4cb9569a1477a40a/test/jdk/tools/jpackage/share/AppContentTest.java#L62).

It turned out that you can have only "Info.plist" file in the "Contents" directory. Any other files should be placed in the "Contents/Resources" directory instead.

This aligns with Apple's recommendations for bundle directory structure - https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW19

jpackage is not quite compliant with these recommendations, as it places the Java runtime in the "Contents/runtime" directory and the application jar files in the "Contents/app" directory. The justification is that this is legacy behavior originating from the JFX's jpackager. Fortunately, this hasn't caused problems so far.

Bottom line: don't copy files or directories with periods (.) in their names to the "Contents" directory. Copy them to the "Contents/Resources" directory instead. Otherwise, codesign will fail.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2838942773

From asemenyuk at openjdk.org  Tue Apr 29 13:40:59 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 29 Apr 2025 13:40:59 GMT
Subject: RFR: 8355651: Issues with post-image hook [v2]
In-Reply-To: <5RuvuTl0kW-MbAAb0sJb1zkBnWUAnNTHKp2r8wQwiz8=.34a6dd59-aa49-4f51-b128-222e4116e922@github.com>
References: <5RuvuTl0kW-MbAAb0sJb1zkBnWUAnNTHKp2r8wQwiz8=.34a6dd59-aa49-4f51-b128-222e4116e922@github.com>
Message-ID: <0BBg6RbUThxeP5kCFXwZZWPKQM26LvwCR3NtGTUkO-I=.ab23eae5-e388-4478-aeaa-ff0ec011d814@github.com>

> - Add missing "post-image" infrastructure on Linux.
>  - Fix "post-image" infrastructure on macOS and Windows.
>  - Add relevant tests.
>  - Update TKit to support new tests.

Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 10 new commits since the last revision:

 - Fix modifiers order
 - Update src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java
   
   Co-authored-by: Hendrik Schick <30866028+ky0n at users.noreply.github.com>
 - Better test coverage
 - Change signature of TKit.assertEquals(String, String, String) to TKit.assertEquals(Object, Object, String)
 - Add Comm.uniqueEmpty()
 - - Add TKit.assertDirectoryContentRecursive()
   - Fix log messages of TKit.assertDirectoryExists()
 - Reorder actions in PKG packaging to ensure user post-image script is invoked before any PKG is created.
 - Fix formatting
 - - Add missing "post-image" script execution to Linux bundlers
   - Add tests to verify the context of "post-image" script on all platforms
   - Set current directory for "post-image" script on Windows and macOS inside of the app image directory
 - 8355651: Premature execution of post-image hook

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24899/files
  - new: https://git.openjdk.org/jdk/pull/24899/files/ec86bb55..be25c5ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24899&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24899&range=00-01

  Stats: 966 lines in 16 files changed: 802 ins; 103 del; 61 mod
  Patch: https://git.openjdk.org/jdk/pull/24899.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24899/head:pull/24899

PR: https://git.openjdk.org/jdk/pull/24899

From duke at openjdk.org  Tue Apr 29 13:40:59 2025
From: duke at openjdk.org (Hendrik Schick)
Date: Tue, 29 Apr 2025 13:40:59 GMT
Subject: RFR: 8355651: Issues with post-image hook [v2]
In-Reply-To: <0BBg6RbUThxeP5kCFXwZZWPKQM26LvwCR3NtGTUkO-I=.ab23eae5-e388-4478-aeaa-ff0ec011d814@github.com>
References: <5RuvuTl0kW-MbAAb0sJb1zkBnWUAnNTHKp2r8wQwiz8=.34a6dd59-aa49-4f51-b128-222e4116e922@github.com>
 <0BBg6RbUThxeP5kCFXwZZWPKQM26LvwCR3NtGTUkO-I=.ab23eae5-e388-4478-aeaa-ff0ec011d814@github.com>
Message-ID: 

On Tue, 29 Apr 2025 13:37:06 GMT, Alexey Semenyuk  wrote:

>> - Add missing "post-image" infrastructure on Linux.
>>  - Fix "post-image" infrastructure on macOS and Windows.
>>  - Add relevant tests.
>>  - Update TKit to support new tests.
>
> Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 10 new commits since the last revision:
> 
>  - Fix modifiers order
>  - Update src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java
>    
>    Co-authored-by: Hendrik Schick <30866028+ky0n at users.noreply.github.com>
>  - Better test coverage
>  - Change signature of TKit.assertEquals(String, String, String) to TKit.assertEquals(Object, Object, String)
>  - Add Comm.uniqueEmpty()
>  - - Add TKit.assertDirectoryContentRecursive()
>    - Fix log messages of TKit.assertDirectoryExists()
>  - Reorder actions in PKG packaging to ensure user post-image script is invoked before any PKG is created.
>  - Fix formatting
>  - - Add missing "post-image" script execution to Linux bundlers
>    - Add tests to verify the context of "post-image" script on all platforms
>    - Set current directory for "post-image" script on Windows and macOS inside of the app image directory
>  - 8355651: Premature execution of post-image hook

src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java line 505:

> 503:         .setScriptNameSuffix("post-image")
> 504:         .setEnvironmentVariable("JpAppImageDir", thePackage.sourceRoot().toAbsolutePath().toString())
> 505:         .run(params);

Suggestion:

              .setDirectory(thePackage.sourceRoot())
              .setResourceCategoryId("resource.post-app-image-script")
              .setScriptNameSuffix("post-image")
              .setEnvironmentVariable("JpAppImageDir", thePackage.sourceRoot().toAbsolutePath().toString())
              .run(params);

8 spaces
(?)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24899#discussion_r2063078074

From michaelm at openjdk.org  Tue Apr 29 14:05:44 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 29 Apr 2025 14:05:44 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v9]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Review update
 - review update
 - Merge branch 'master' into 8348986-exceptions
 - update to minimise code changes
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Apply suggestions from code review
   
   from turbanoff review
   
   Co-authored-by: Andrey Turbanov 
 - doc + copyright update
 - ... and 13 more: https://git.openjdk.org/jdk/compare/6a0c24f9...1a14f4bd

-------------

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=08
  Stats: 949 lines in 42 files changed: 716 ins; 101 del; 132 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From rriggs at openjdk.org  Tue Apr 29 14:17:06 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Apr 2025 14:17:06 GMT
Subject: RFR: 8351000: StringBuilder getChar and putChar robustness
Message-ID: 

Improve StringBuilder getChar and putChar robustness with racy updates to StringBuilder. 
Test racing threads with append, insert, and reading characters.

-------------

Commit messages:
 - 8351000: StringBuilder getChar and putChar robustness

Changes: https://git.openjdk.org/jdk/pull/24951/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24951&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351000
  Stats: 314 lines in 2 files changed: 309 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24951.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24951/head:pull/24951

PR: https://git.openjdk.org/jdk/pull/24951

From liach at openjdk.org  Tue Apr 29 14:17:09 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 14:17:09 GMT
Subject: RFR: 8351000: StringBuilder getChar and putChar robustness
In-Reply-To: 
References: 
Message-ID: 

On Tue, 29 Apr 2025 14:10:30 GMT, Roger Riggs  wrote:

> Improve StringBuilder getChar and putChar robustness with racy updates to StringBuilder. 
> Test racing threads with append, insert, and reading characters.

test/jdk/java/lang/StringBuilder/RacingSBThreads.java line 27:

> 25:  * @test
> 26:  * @summary Test multi-threaded use of StringBuilder
> 27:  * @compile --release 8 RacingSBThreads.java

Is there a reason for this specific release number?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24951#discussion_r2066636836

From archie.cobbs at gmail.com  Tue Apr 29 14:17:43 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 29 Apr 2025 09:17:43 -0500
Subject: Runtime.exec and SIGPIPE + SIG_IGN
In-Reply-To: 
References: 
Message-ID: 

This reminds me of a bug I saw once decades ago: the JVM was not setting
the close-on-exec flag on new file descriptors, so child processes were
receiving copies of "leaked" file descriptors and keeping them open
indefinitely, causing the system to eventually running out of file
descriptors and crash.

The moral of that story was that control of the "process environment" of a
new process (i.e., which file descriptors are open, signal handlers
installed, etc.) created via the usual fork/exec sequence clearly belongs
to the bit of code that is spawning that process for whatever reason: any
inheritable part of the process environment that the JVM might mess around
with must be reset before spawning child processes.

So if some native code wants to configure SIGPIPE for SIG_IGN and then
fork/exec a child process that inherits that setting, then fine.

But if the JVM itself is doing its fork/exec for some unrelated purpose
(e.g., Runtime.exec()), it has the right and responsibility to clean up the
environment that the child process is going to inherit to protect it from
any changes due to the JVM process, including native code.

So it seems like there are two possible bugs here:

1. Some JNI code links in a library that changes the (global) setting for
SIGPIPE. Is that allowed by the JNI specification? Does the specification
even say? It seems like this is not really kosher, but anyway it happens to
work by coincidence because SIG_IGN and javaSignalHandler do the same thing
(i.e., discard the signal).

2. The JVM is not completely scrubbing the child's process environment when
it spawns a new process as it should: All signal handlers should be reset
to their default values (unless there is some JVM-specific reason to set
them differently).

It seems like #2 is a valid bug or at least a valid improvement, and
whether #1 is a bug depends on what you believe JNI libraries are
officially allowed to do.

-Archie

On Tue, Apr 29, 2025 at 4:05?AM Thomas St?fe 
wrote:

> Hi,
>
> I would like to gauge opinions on whether the following scenario is a bug
> to fix or whether to accept it as standard behavior.
>
> ---
>
> A customer has the following problem:
>
> - The JVM invokes a third-party JNI library that sets the signal
> disposition of SIGPIPE to SIG_IGN (Boo! in this case, it is the FIPS nspr
> library, which does this unconditionally.)
> - The JVM then spawns child processes
> - All child processes now ignore SIGPIPE, which leads to failures in
> automation scripts
>
> I was surprised. I always assumed the signal disposition of all signals
> would be reset to SIG_DFL when exec'ing. However, seems I was wrong when it
> came to SIG_IGN. Posix documents for execve() states [1]:
>
> 1) " Signals set to the default action (SIG_DFL) in the calling process
> image shall be set to the default action in the new process image."
>
> and
>
> 2) "Except for SIGCHLD, signals set to be ignored (SIG_IGN) by the calling
> process image shall be set to be ignored by the new process image."
>
> and
>
> 3) "Signals set to be caught by the calling process image shall be set to
> the default action in the new process image (see **
> 
> )."
>
> (2) and (3) are the interesting parts. (2) means that if the parent
> process ignores SIGPIPE, child processes will also ignore SIGPIPE. (3)
> means that if the parent process has a custom handler installed for
> SIGPIPE, child processes will be started with SIG_DFL (default action) for
> SIGPIPE. The default action for SIGPIPE is "terminate process".
> The libjvm handles SIGPIPE. We install our `javaSignalHandler`. We do this
> to eat up and ignore SIGPIPE. That we "manually" ignore the signal beside
> the point here - what counts is that we set a custom signal handler for
> SIGPIPE. Therefore, on execve, we behave according to rule (3) and start
> the child with SIG_DFL as SIGPIPE disposition. As it should be.
>
> If third-party code sets the handler to SIG_IGN as in this example, exeve
> will behave according to rule (2) and the child will start with SIG_IGN as
> SIGPIPE disposition.
>
> The libjig can be used to workaround this scenario, but I wonder if that
> is more of an accident. The libjsig.so will preserve the JVM's SIGPIPE
> handler even if third-party code attempts to set it to SIG_IGN. That means
> that exeve still behaves according to rule (2): sets child's SIGPIPE
> disposition to SIG_DFL.
>
> ----
>
> But I wonder whether this should not be considered a bug to fix regardless
> of the jsig.so workaround? In jspawnhelper, we clean the environment from
> various effects when exec'ing; among other things, we reset the signal
> block mask for the process. The "ignore" state of processes could be
> considered along the same line. We could reset all signal handlers to
> SIG_DFL before execing the child.
>
> I know that this area is super-tricky and problems are notoriously
> difficult to analyze; we should therefore be extremely careful not to break
> downward compatibility. Still, what do people think? Should be fix this in
> jspawnhelper?
>
> Thanks, Thomas
>
> (cc'ing Roger)
>
> [1] https://pubs.opengroup.org/onlinepubs/009695399/functions/exec.html
>


-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From liach at openjdk.org  Tue Apr 29 14:19:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 14:19:51 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 12:33:34 GMT, Per Minborg  wrote:

>> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
>> 
>> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
>> 
>> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
>> 
>> 
>> Here are some benchmarks that ran on a platform thread and virtual threads respectively (M1 Mac):
>> 
>> 
>> Benchmark                                                  Mode  Cnt   Score   Error  Units
>> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.330 ? 0.820  ns/op
>> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.257 ? 0.117  ns/op
>> CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  41.415 ? 1.013  ns/op
>> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.720 ? 0.463  ns/op
>> CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.636 ? 0.182  ns/op
>> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.234 ? 0.156  ns/op
>> CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.918 ? 0.487  ns/op
>> CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   4.946 ? 0.089  ns/op
>> CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.280 ? 1.128  ns/op
>> CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  21.809 ? 0.413  ns/op
>> CaptureStateUtilBench.tlAllocationFail                     avgt   30  24.422 ? 0.673  ns/op
>> CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   5.182 ? 0.152  ns/op
>> 
>> 
>> Adapted system call:
>> 
>>         return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool
>> ```        
>> Explicit allocation:
>> 
>>         try (var arena = Arena.ofConfined()) {
>>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
>>         }
>> ```        
>> Thread Local allocation:
>> 
>>         try (var arena = POOLS.take()) {
>>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool
>>         }
>> ```        
>> The adapted system call exhibits a ~4x performance improvement ove...
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add hashCode/equals to record to improve startup time

The code looks good to me; please wait for people more professional with FFM internals like @JornVernee or @mcimadamore.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23765#issuecomment-2839102820

From rriggs at openjdk.org  Tue Apr 29 14:21:48 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Apr 2025 14:21:48 GMT
Subject: RFR: 8351000: StringBuilder getChar and putChar robustness
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 14:13:20 GMT, Chen Liang  wrote:

>> Improve StringBuilder getChar and putChar robustness with racy updates to StringBuilder. 
>> Test racing threads with append, insert, and reading characters.
>
> test/jdk/java/lang/StringBuilder/RacingSBThreads.java line 27:
> 
>> 25:  * @test
>> 26:  * @summary Test multi-threaded use of StringBuilder
>> 27:  * @compile --release 8 RacingSBThreads.java
> 
> Is there a reason for this specific release number?

Yes, so the test can be compiled and run on older versions. Specifically, restricting the use of String.repeat.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24951#discussion_r2066663882

From duke at openjdk.org  Tue Apr 29 14:28:32 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Apr 2025 14:28:32 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v43]
In-Reply-To: 
References: 
Message-ID: 

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Removed needless condition

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/d85a634e..9a5d6965

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=42
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=41-42

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From henryjen at openjdk.org  Tue Apr 29 14:31:49 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 29 Apr 2025 14:31:49 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 29 Apr 2025 00:02:58 GMT, Chen Liang  wrote:

>> 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 three additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'openjdk/master' into open
>>  - Enhance validation output to be more specific
>>  - 8345431: Detect duplicate entries in jar files with jar --validate
>
> src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 89:
> 
>> 87: 
>> 88:     // Check if CEN contains the LOC entry by name
>> 89:     private boolean checkHasCenEntry(String locEntryName) {
> 
> This method name and comment does not indicate a match is removed like the name `Next` in `checkNextCenEntry` implies - I suggest some way to indicate that a match is removed, like `checkUnorderedCenEntry`. `Has` implies a read-only operation that performs no modification.

checkAnyCenEntry, Any vs Next make it relatively obvious on the difference.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2066702548

From duke at openjdk.org  Tue Apr 29 14:37:35 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Apr 2025 14:37:35 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v44]
In-Reply-To: 
References: 
Message-ID: 

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Don't exclude a priori valid results
  
  Don't exclude a priori values that may be inside the supported range, leave the bound checks to the subroutines.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/9a5d6965..6033d256

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=43
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=42-43

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From henryjen at openjdk.org  Tue Apr 29 14:39:19 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 29 Apr 2025 14:39:19 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v3]
In-Reply-To: 
References: 
Message-ID: 

> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Rename checkHasCenEntry to checkAnyCenEntry

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/384905bc..d56eb76c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=01-02

  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24430/head:pull/24430

PR: https://git.openjdk.org/jdk/pull/24430

From cstein at openjdk.org  Tue Apr 29 14:39:19 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 29 Apr 2025 14:39:19 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 14:36:37 GMT, Henry Jen  wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename checkHasCenEntry to checkAnyCenEntry

test/jdk/tools/jar/ValidatorTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2025, 2025, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.


One year is enough here, right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2066717887

From duke at openjdk.org  Tue Apr 29 14:41:07 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Apr 2025 14:41:07 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v45]
In-Reply-To: 
References: 
Message-ID: 

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Take into account special case exponent == 1

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/6033d256..5deb21ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=44
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=43-44

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From duke at openjdk.org  Tue Apr 29 14:45:25 2025
From: duke at openjdk.org (PAWAN CHAWDHARY)
Date: Tue, 29 Apr 2025 14:45:25 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails

PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:

  update reference of DockerVersion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24948/files
  - new: https://git.openjdk.org/jdk/pull/24948/files/b2c2cc43..223a5d1b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=00-01

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/24948.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24948/head:pull/24948

PR: https://git.openjdk.org/jdk/pull/24948

From shade at openjdk.org  Tue Apr 29 14:45:55 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 29 Apr 2025 14:45:55 GMT
Subject: RFR: 8342283: CDS cannot handle a large number of classes [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Apr 2025 09:20:38 GMT, Aleksey Shipilev  wrote:

>> CDS cannot handle large number of classes, because `ClassLoader` data structures get too large for CDS archival. The new test captures such an occasion. We do `clear()`-s, but that is not enough to trim the backing storages for the affected collections.
>> 
>> In contrast with previous attempts to fix this (https://github.com/openjdk/jdk/pull/21797 and my VM-side field overwrite), we can just reinitialize the fields using `Unsafe`, which bypasses normal `final` field write restriction. `ClassLoader` already does a similar thing nearby! This allows us to stay fully in Java, and makes the patch fairly straightforward.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, new test reliably fails without the fix, passes with it
>>  - [x] Linux x86_64 server fastdebug, `runtime/cds`
>
> 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:
> 
>  - Minor touchup
>  - Merge branch 'master' into JDK-8342283-cds-many-classes
>  - Adjust TEST.groups
>  - Fix

Are we still good with this? Integration need a re-review :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24877#issuecomment-2839196848

From iklam at openjdk.org  Tue Apr 29 14:54:50 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 29 Apr 2025 14:54:50 GMT
Subject: RFR: 8342283: CDS cannot handle a large number of classes [v2]
In-Reply-To: 
References: 
 
Message-ID: <6x3GHbFafnGvURaNn4URmJE26qadC2IDZUvA_Z9AxV0=.6c7e4f1f-afd6-4e1d-acd0-fc85967d335b@github.com>

On Mon, 28 Apr 2025 09:20:38 GMT, Aleksey Shipilev  wrote:

>> CDS cannot handle large number of classes, because `ClassLoader` data structures get too large for CDS archival. The new test captures such an occasion. We do `clear()`-s, but that is not enough to trim the backing storages for the affected collections.
>> 
>> In contrast with previous attempts to fix this (https://github.com/openjdk/jdk/pull/21797 and my VM-side field overwrite), we can just reinitialize the fields using `Unsafe`, which bypasses normal `final` field write restriction. `ClassLoader` already does a similar thing nearby! This allows us to stay fully in Java, and makes the patch fairly straightforward.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, new test reliably fails without the fix, passes with it
>>  - [x] Linux x86_64 server fastdebug, `runtime/cds`
>
> 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:
> 
>  - Minor touchup
>  - Merge branch 'master' into JDK-8342283-cds-many-classes
>  - Adjust TEST.groups
>  - Fix

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24877#pullrequestreview-2803995873

From thomas.stuefe at gmail.com  Tue Apr 29 14:55:32 2025
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 29 Apr 2025 16:55:32 +0200
Subject: Runtime.exec and SIGPIPE + SIG_IGN
In-Reply-To: 
References: 
 
Message-ID: 

Hi Archie!

On Tue, Apr 29, 2025 at 4:17?PM Archie Cobbs  wrote:

> This reminds me of a bug I saw once decades ago: the JVM was not setting
> the close-on-exec flag on new file descriptors, so child processes were
> receiving copies of "leaked" file descriptors and keeping them open
> indefinitely, causing the system to eventually running out of file
> descriptors and crash.
>
>
I remember. We fixed that in jspawnhelper.


> The moral of that story was that control of the "process environment" of a
> new process (i.e., which file descriptors are open, signal handlers
> installed, etc.) created via the usual fork/exec sequence clearly belongs
> to the bit of code that is spawning that process for whatever reason: any
> inheritable part of the process environment that the JVM might mess around
> with must be reset before spawning child processes.
>
>
Agreed.


> So if some native code wants to configure SIGPIPE for SIG_IGN and then
> fork/exec a child process that inherits that setting, then fine.
>
> But if the JVM itself is doing its fork/exec for some unrelated purpose
> (e.g., Runtime.exec()), it has the right and responsibility to clean up the
> environment that the child process is going to inherit to protect it from
> any changes due to the JVM process, including native code.
>
> So it seems like there are two possible bugs here:
>
> 1. Some JNI code links in a library that changes the (global) setting for
> SIGPIPE. Is that allowed by the JNI specification? Does the specification
> even say? It seems like this is not really kosher, but anyway it happens to
> work by coincidence because SIG_IGN and javaSignalHandler do the same thing
> (i.e., discard the signal).
>
>
To my knowledge the JNI spec says nothing about signals.



> 2. The JVM is not completely scrubbing the child's process environment
> when it spawns a new process as it should: All signal handlers should be
> reset to their default values (unless there is some JVM-specific reason to
> set them differently).
>
> It seems like #2 is a valid bug or at least a valid improvement, and
> whether #1 is a bug depends on what you believe JNI libraries are
> officially allowed to do.
>
>
I agree. Note that we also have a slight inconsistency depending on the
order of third-party signal handler installation:

1) In a scenario like the one I described we start java, it installs the
SIGPIPE handler, which then gets preplaced by the third-party lib with
SIG_IGN, resulting in child processes running with SIG_IGN for SIGPIPE.
2) If, however,r the libjvm.so gets embedded into a custom launcher, which
already had set SIG_IGN for SIGPIPE, the JVM will replace that handler with
its own, resulting in child processes running with SIG_DFL.

This seems a bit arbitrary to me and seems to support the view that this
behavior is not intended.


> -Archie
>
> On Tue, Apr 29, 2025 at 4:05?AM Thomas St?fe 
> wrote:
>
>> Hi,
>>
>> I would like to gauge opinions on whether the following scenario is a bug
>> to fix or whether to accept it as standard behavior.
>>
>> ---
>>
>> A customer has the following problem:
>>
>> - The JVM invokes a third-party JNI library that sets the signal
>> disposition of SIGPIPE to SIG_IGN (Boo! in this case, it is the FIPS nspr
>> library, which does this unconditionally.)
>> - The JVM then spawns child processes
>> - All child processes now ignore SIGPIPE, which leads to failures in
>> automation scripts
>>
>> I was surprised. I always assumed the signal disposition of all signals
>> would be reset to SIG_DFL when exec'ing. However, seems I was wrong when it
>> came to SIG_IGN. Posix documents for execve() states [1]:
>>
>> 1) " Signals set to the default action (SIG_DFL) in the calling process
>> image shall be set to the default action in the new process image."
>>
>> and
>>
>> 2) "Except for SIGCHLD, signals set to be ignored (SIG_IGN) by the
>> calling process image shall be set to be ignored by the new process image."
>>
>> and
>>
>> 3) "Signals set to be caught by the calling process image shall be set to
>> the default action in the new process image (see **
>> 
>> )."
>>
>> (2) and (3) are the interesting parts. (2) means that if the parent
>> process ignores SIGPIPE, child processes will also ignore SIGPIPE. (3)
>> means that if the parent process has a custom handler installed for
>> SIGPIPE, child processes will be started with SIG_DFL (default action) for
>> SIGPIPE. The default action for SIGPIPE is "terminate process".
>> The libjvm handles SIGPIPE. We install our `javaSignalHandler`. We do
>> this to eat up and ignore SIGPIPE. That we "manually" ignore the signal
>> beside the point here - what counts is that we set a custom signal handler
>> for SIGPIPE. Therefore, on execve, we behave according to rule (3) and
>> start the child with SIG_DFL as SIGPIPE disposition. As it should be.
>>
>> If third-party code sets the handler to SIG_IGN as in this example, exeve
>> will behave according to rule (2) and the child will start with SIG_IGN as
>> SIGPIPE disposition.
>>
>> The libjig can be used to workaround this scenario, but I wonder if that
>> is more of an accident. The libjsig.so will preserve the JVM's SIGPIPE
>> handler even if third-party code attempts to set it to SIG_IGN. That means
>> that exeve still behaves according to rule (2): sets child's SIGPIPE
>> disposition to SIG_DFL.
>>
>> ----
>>
>> But I wonder whether this should not be considered a bug to fix
>> regardless of the jsig.so workaround? In jspawnhelper, we clean the
>> environment from various effects when exec'ing; among other things, we
>> reset the signal block mask for the process. The "ignore" state of
>> processes could be considered along the same line. We could reset all
>> signal handlers to SIG_DFL before execing the child.
>>
>> I know that this area is super-tricky and problems are notoriously
>> difficult to analyze; we should therefore be extremely careful not to break
>> downward compatibility. Still, what do people think? Should be fix this in
>> jspawnhelper?
>>
>> Thanks, Thomas
>>
>> (cc'ing Roger)
>>
>> [1] https://pubs.opengroup.org/onlinepubs/009695399/functions/exec.html
>>
>
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From shade at openjdk.org  Tue Apr 29 15:07:51 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 29 Apr 2025 15:07:51 GMT
Subject: RFR: 8342283: CDS cannot handle a large number of classes [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Apr 2025 09:20:38 GMT, Aleksey Shipilev  wrote:

>> CDS cannot handle large number of classes, because `ClassLoader` data structures get too large for CDS archival. The new test captures such an occasion. We do `clear()`-s, but that is not enough to trim the backing storages for the affected collections.
>> 
>> In contrast with previous attempts to fix this (https://github.com/openjdk/jdk/pull/21797 and my VM-side field overwrite), we can just reinitialize the fields using `Unsafe`, which bypasses normal `final` field write restriction. `ClassLoader` already does a similar thing nearby! This allows us to stay fully in Java, and makes the patch fairly straightforward.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, new test reliably fails without the fix, passes with it
>>  - [x] Linux x86_64 server fastdebug, `runtime/cds`
>
> 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:
> 
>  - Minor touchup
>  - Merge branch 'master' into JDK-8342283-cds-many-classes
>  - Adjust TEST.groups
>  - Fix

Thank you! I am running final `tier{1,2,3}` testing before integration, and will integrate when those turn green.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24877#issuecomment-2839269179

From duke at openjdk.org  Tue Apr 29 15:10:10 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Apr 2025 15:10:10 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v46]
In-Reply-To: 
References: 
Message-ID: <3O57UNZ3SXn29fLVtLJ2hm43d798Vt40EIjcvqbcMus=.e8a5dc7a-bb21-44ec-ad66-c11e0a23456f@github.com>

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:

 - Adjust the type of operand
 - Use a more loose formula to do range check
   
   Use a more loose formula to do range check, in order not to exclude a priori values that may be inside the supported range

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/5deb21ae..925806bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=45
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=44-45

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From archie.cobbs at gmail.com  Tue Apr 29 15:12:15 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 29 Apr 2025 10:12:15 -0500
Subject: Runtime.exec and SIGPIPE + SIG_IGN
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, Apr 29, 2025 at 9:55?AM Thomas St?fe 
wrote:

> 1) In a scenario like the one I described we start java, it installs the
> SIGPIPE handler, which then gets preplaced by the third-party lib with
> SIG_IGN, resulting in child processes running with SIG_IGN for SIGPIPE.
> 2) If, however,r the libjvm.so gets embedded into a custom launcher, which
> already had set SIG_IGN for SIGPIPE, the JVM will replace that handler with
> its own, resulting in child processes running with SIG_DFL.
>
> This seems a bit arbitrary to me and seems to support the view that this
> behavior is not intended.
>

Agreed - water appearing randomly in the bottom of your boat is usually
evidence of a leak somewhere :)

Shouldn't the environment of a new child process created via Runtime.exec()
be the same no matter when or how it was created? Other than any state that
derives from the parameters to that method of course.

Practically speaking, it's hard to imagine fixing this would break anything
out there. It seems more likely that it would accidentally fix something,
so to speak.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rgiulietti at openjdk.org  Tue Apr 29 15:20:48 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 29 Apr 2025 15:20:48 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v46]
In-Reply-To: <3O57UNZ3SXn29fLVtLJ2hm43d798Vt40EIjcvqbcMus=.e8a5dc7a-bb21-44ec-ad66-c11e0a23456f@github.com>
References: 
 <3O57UNZ3SXn29fLVtLJ2hm43d798Vt40EIjcvqbcMus=.e8a5dc7a-bb21-44ec-ad66-c11e0a23456f@github.com>
Message-ID: <3SCIKgVUu2jWXZUEtneJW15plxLd327-K7RjQrvIxQI=.bbcb09b5-e1ab-41d3-a777-620b960ffdfc@github.com>

On Tue, 29 Apr 2025 15:10:10 GMT, fabioromano1  wrote:

>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>
> fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adjust the type of operand
>  - Use a more loose formula to do range check
>    
>    Use a more loose formula to do range check, in order not to exclude a priori values that may be inside the supported range

Thanks.

What went wrong before?
> Instead, when I try to run the tests with a custom JVM, unfortunately I get this Exception:
> 
> Exception in thread "main" java.lang.RuntimeException: ERROR: Unable to find the resource: /META-INF/BenchmarkList
>         at org.openjdk.jmh.runner.AbstractResourceReader.getReaders(AbstractResourceReader.java:98)
>         at org.openjdk.jmh.runner.BenchmarkList.find(BenchmarkList.java:124)
>         at org.openjdk.jmh.runner.Runner.internalRun(Runner.java:252)
>         at org.openjdk.jmh.runner.Runner.run(Runner.java:208)
>         at org.openjdk.jmh.Main.main(Main.java:71)
> 

Some observations:
- You should really compare before/after on the otherwise same environment, here JDK 25-internal. Comparing JDK 21.0.7-ea (which is an early-access release) and JDK 25-internal might not be that meaningful. In the meantime there have been improvements in the runtime, GC, etc.
- AFAIU, your Linux OS runs in some virtualized environment (e.g., VirtualBox). It would be better to use some native installation, but I understand this is not always feasible.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2839315518

From jvernee at openjdk.org  Tue Apr 29 15:29:19 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 29 Apr 2025 15:29:19 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v78]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 24 Apr 2025 10:37:59 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make public constuctor private

Looks mostly good. Left a few more inline comments

src/java.base/share/classes/java/lang/StableValue.java line 618:

> 616:      *
> 617:      * @param size       the size of the allowed inputs in the continuous
> 618:      *                   interval {@code [0, size)}

"Size of allowed inputs" doesn't seem quite right, maybe:

Suggestion:

     * @param size       the upper bound of the range {@code [0, size)} indicating the allowed inputs

src/java.base/share/classes/java/lang/StableValue.java line 619:

> 617:      * @param size       the size of the allowed inputs in the continuous
> 618:      *                   interval {@code [0, size)}
> 619:      * @param underlying IntFunction used to compute cached values

Suggestion:

     * @param underlying {@code IntFunction} used to compute cached values

test/jdk/java/lang/StableValue/StableFunctionTest.java line 79:

> 77:     void factoryInvariants(Set inputs) {
> 78:         assertThrows(NullPointerException.class, () -> StableValue.function(null, MAPPER));
> 79:         assertThrows(NullPointerException.class, () -> StableValue.function(inputs, null));

I think you also need a case for `null` elements in `inputs`

test/jdk/java/lang/StableValue/StableValueTest.java line 373:

> 371:                 .toList();
> 372:         threads.forEach(Thread::start);
> 373:         LockSupport.parkNanos(TimeUnit.MILLISECONDS.toNanos(1));

Instead of parking and calling `countDown` here, which might be unreliable if a particular thread doesn't get scheduled, you could set the latch value to `noThreads`, and then do a `starter.countDown()` before calling `await`. That should start all the threads running at the same time once all of them are ready.

test/micro/org/openjdk/bench/java/lang/stable/StableMethodHandleBenchmark.java line 121:

> 119:                 cp.nameAndTypeEntry(DEFAULT_NAME, CD_MethodHandle)));
> 120:         return null;
> 121:     }

Seems unused

-------------

PR Review: https://git.openjdk.org/jdk/pull/23972#pullrequestreview-2803046751
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2066109981
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2066113200
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2066747882
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2066781044
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2066809541

From jvernee at openjdk.org  Tue Apr 29 15:36:45 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 29 Apr 2025 15:36:45 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
In-Reply-To: 
References: 
Message-ID: 

On Wed, 23 Apr 2025 14:05:58 GMT, Per Minborg  wrote:

> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
> 
> Re-allocated segments are not zeroed between allocations.

We can not just re-use the original test due to: https://bugs.openjdk.org/browse/JDK-8350455

See my comment here: https://github.com/openjdk/jdk/pull/23142#issuecomment-2673194510

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2839363856

From liach at openjdk.org  Tue Apr 29 15:42:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 15:42:49 GMT
Subject: RFR: 8351000: StringBuilder getChar and putChar robustness
In-Reply-To: 
References: 
Message-ID: 

On Tue, 29 Apr 2025 14:10:30 GMT, Roger Riggs  wrote:

> Improve StringBuilder getChar and putChar robustness with racy updates to StringBuilder. 
> Test racing threads with append, insert, and reading characters.

Thanks, other changes look good to me!

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24951#pullrequestreview-2804165927

From liach at openjdk.org  Tue Apr 29 15:44:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 15:44:54 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v3]
In-Reply-To: 
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 
Message-ID: 

On Mon, 28 Apr 2025 14:36:33 GMT, Chen Liang  wrote:

>> Perf numbers for simple main:
>> Linking of `Class::forName0` down from ~152 to ~83
>> 
>> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
>> JNI: ~45
>> baseline panama: ~164
>> patch: ~103
>> 
>> Also see #24705.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
>  - Use more simple function descriptor
>  - Simplify FFM linker warmup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
>  - Wip work trying to speed up FFM

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24742#issuecomment-2839386299

From liach at openjdk.org  Tue Apr 29 15:44:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 15:44:55 GMT
Subject: Integrated: 8354996: Reduce dynamic code generation for a single
 downcall
In-Reply-To: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
Message-ID: 

On Thu, 17 Apr 2025 19:44:07 GMT, Chen Liang  wrote:

> Perf numbers for simple main:
> Linking of `Class::forName0` down from ~152 to ~83
> 
> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
> JNI: ~45
> baseline panama: ~164
> patch: ~103
> 
> Also see #24705.

This pull request has now been integrated.

Changeset: 5d2d1ab5
Author:    Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/5d2d1ab5740259bc30d0184e4d691a05fdf63e19
Stats:     132 lines in 7 files changed: 113 ins; 0 del; 19 mod

8354996: Reduce dynamic code generation for a single downcall

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/24742

From asemenyuk at openjdk.org  Tue Apr 29 15:45:02 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 29 Apr 2025 15:45:02 GMT
Subject: RFR: 8319457: Update jpackage to support WiX v4 and v5 on Windows
In-Reply-To: <9yH-cW3pckTJWtokFbmYu6NOtZ7lTfLHJSUmEFMQows=.52fe3bca-be29-4888-9a50-617cdec5c8cb@github.com>
References: 
 
 
 
 
 
 
 <9yH-cW3pckTJWtokFbmYu6NOtZ7lTfLHJSUmEFMQows=.52fe3bca-be29-4888-9a50-617cdec5c8cb@github.com>
Message-ID: 

On Sat, 26 Apr 2025 13:17:16 GMT, Oliver Kopp  wrote:

>>> jpackage allows override of main WiX source file (main.wxs), do you know what will happen if user will add main.wxs with format features available only in WiX 5 and will have WiX 5 toolkit installed?
>> 
>> jpackage will detect the custom main.wxs is WiX4 format and pass it as is to `wix.exe`. I.e. custom WiX5 main.wxs will work with WiX5 toolkit.
>> However, it will fail if they try using custom main.wxs with WiX5-specific features with WiX4 toolkit. But this is out of the scope of jpackage.
>> 
>>> Do you know if there any benefits to use any features available in WiX5 if WiX5 toolkit is installed, instead of using only WiX4 features with WiX5 toolkit?
>> 
>> As far as I can tell from https://wixtoolset.org/docs/fivefour/, WiX5 reduces the redundancy of source files compared to WiX4. I can see how people handwriting sophisticated WiX source files can benefit from these improvements, not jpackage. The default main.wxs and two dialogs jpackage supplies are very basic and other sources are generated.
>
>> jpackage allows override of main WiX source file (main.wxs), do you know what will happen if user will add main.wxs with format features available only in WiX 5 and will have WiX 5 toolkit installed?
> 
> @alexeysemenyukoracle Related question: Generation of `main.wxs` was moved from `prepareMainProjectFile` to `buildMSI`. This breaks [our patches to](https://github.com/JabRef/jabref/blob/95dcbe64659ced52627e012f2b6b5a60a9bb21b1/buildres/windows/JabRef-post-image.wsf#L18) `main.wxs` (which used to work for 6+ years now) 
> 
> Quoting https://docs.oracle.com/en/java/javase/24/jpackage/override-jpackage-resources.html#GUID-62412365-821D-4736-A20D-70F2D47136D8, the `post-image` script is executed before `buildMSI` (which is right).
> 
>> Custom script that is **executed after the application image** is created and **before the MSI installer is built** for both .msi and .exe packages. No default script is provided. 
> 
> I would expect that all files are available before the "Post-image script" are available - and not generated **after** any **Post**-image script is run.

@koppor , ["JabRef post-image" script](https://github.com/JabRef/jabref/blob/95dcbe64659ced52627e012f2b6b5a60a9bb21b1/buildres/windows/JabRef-post-image.wsf#L18) has a couple of issues:
 - A path to the "config" directory is derived from the current process directory. This logic is fragile and redundant. jpackage runs a copy of the "post-image" script from the "config" directory, so the path to the "config" directory is the parent folder of the script:

var installerConfig = fileSystem.GetFile(WScript.ScriptFullName).ParentFolder;

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19318#issuecomment-2839387341

From rgiulietti at openjdk.org  Tue Apr 29 15:45:49 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 29 Apr 2025 15:45:49 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v46]
In-Reply-To: <3O57UNZ3SXn29fLVtLJ2hm43d798Vt40EIjcvqbcMus=.e8a5dc7a-bb21-44ec-ad66-c11e0a23456f@github.com>
References: 
 <3O57UNZ3SXn29fLVtLJ2hm43d798Vt40EIjcvqbcMus=.e8a5dc7a-bb21-44ec-ad66-c11e0a23456f@github.com>
Message-ID: 

On Tue, 29 Apr 2025 15:10:10 GMT, fabioromano1  wrote:

>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>
> fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adjust the type of operand
>  - Use a more loose formula to do range check
>    
>    Use a more loose formula to do range check, in order not to exclude a priori values that may be inside the supported range

I don't observe any significant difference on my environment

macOS 15.4.1 / M1 Pro / 32 GiB / java 25-internal

before
----

Benchmark                                   Mode  Cnt            Score            Error   Units
BigIntegerPow.testPowL                      avgt    3   7466740027.667 ? 1815231444.569   ns/op
BigIntegerPow.testPowL:gc.alloc.rate        avgt    3         3964.967 ?        970.175  MB/sec
BigIntegerPow.testPowL:gc.alloc.rate.norm   avgt    3  31040625701.333 ?        337.057    B/op
BigIntegerPow.testPowL:gc.count             avgt    3          201.000                   counts
BigIntegerPow.testPowL:gc.time              avgt    3          145.000                       ms
BigIntegerPow.testPowM                      avgt    3   5281109916.667 ? 1387864024.559   ns/op
BigIntegerPow.testPowM:gc.alloc.rate        avgt    3         3718.944 ?        968.869  MB/sec
BigIntegerPow.testPowM:gc.alloc.rate.norm   avgt    3  20592088429.333 ?        337.057    B/op
BigIntegerPow.testPowM:gc.count             avgt    3          135.000                   counts
BigIntegerPow.testPowM:gc.time              avgt    3           98.000                       ms
BigIntegerPow.testPowS                      avgt    3   5195628500.333 ?  738936923.575   ns/op
BigIntegerPow.testPowS:gc.alloc.rate        avgt    3         3758.710 ?        534.778  MB/sec
BigIntegerPow.testPowS:gc.alloc.rate.norm   avgt    3  20477396224.000 ?          0.001    B/op
BigIntegerPow.testPowS:gc.count             avgt    3          135.000                   counts
BigIntegerPow.testPowS:gc.time              avgt    3           94.000                       ms
BigIntegerPow.testPowXL                     avgt    3   8125774666.667 ? 1137294539.763   ns/op
BigIntegerPow.testPowXL:gc.alloc.rate       avgt    3         4120.707 ?        577.639  MB/sec
BigIntegerPow.testPowXL:gc.alloc.rate.norm  avgt    3  35109921325.333 ?        337.057    B/op
BigIntegerPow.testPowXL:gc.count            avgt    3          231.000                   counts
BigIntegerPow.testPowXL:gc.time             avgt    3          161.000                       ms
BigIntegerPow.testPowXS                     avgt    3   4631164917.000 ?  354282119.389   ns/op
BigIntegerPow.testPowXS:gc.alloc.rate       avgt    3         3879.394 ?        297.057  MB/sec
BigIntegerPow.testPowXS:gc.alloc.rate.norm  avgt    3  18839312808.000 ?          0.001    B/op
BigIntegerPow.testPowXS:gc.count            avgt    3          124.000                   counts
BigIntegerPow.testPowXS:gc.time             avgt    3           85.000                       ms


after
----

Benchmark                                   Mode  Cnt            Score            Error   Units
BigIntegerPow.testPowL                      avgt    3   7502352027.667 ? 1599949168.779   ns/op
BigIntegerPow.testPowL:gc.alloc.rate        avgt    3         3946.047 ?        845.736  MB/sec
BigIntegerPow.testPowL:gc.alloc.rate.norm   avgt    3  31040625690.667 ?        337.057    B/op
BigIntegerPow.testPowL:gc.count             avgt    3          202.000                   counts
BigIntegerPow.testPowL:gc.time              avgt    3          143.000                       ms
BigIntegerPow.testPowM                      avgt    3   5269442569.333 ?  869646901.137   ns/op
BigIntegerPow.testPowM:gc.alloc.rate        avgt    3         3724.365 ?        638.773  MB/sec
BigIntegerPow.testPowM:gc.alloc.rate.norm   avgt    3  20578167389.333 ?  439892039.777    B/op
BigIntegerPow.testPowM:gc.count             avgt    3          135.000                   counts
BigIntegerPow.testPowM:gc.time              avgt    3           93.000                       ms
BigIntegerPow.testPowS                      avgt    3   5186210888.667 ?  723686794.493   ns/op
BigIntegerPow.testPowS:gc.alloc.rate        avgt    3         3765.528 ?        523.216  MB/sec
BigIntegerPow.testPowS:gc.alloc.rate.norm   avgt    3  20477396224.000 ?          0.001    B/op
BigIntegerPow.testPowS:gc.count             avgt    3          134.000                   counts
BigIntegerPow.testPowS:gc.time              avgt    3           94.000                       ms
BigIntegerPow.testPowXL                     avgt    3   8153839055.667 ? 1004638585.690   ns/op
BigIntegerPow.testPowXL:gc.alloc.rate       avgt    3         4106.489 ?        506.894  MB/sec
BigIntegerPow.testPowXL:gc.alloc.rate.norm  avgt    3  35109921325.333 ?        337.057    B/op
BigIntegerPow.testPowXL:gc.count            avgt    3          230.000                   counts
BigIntegerPow.testPowXL:gc.time             avgt    3          158.000                       ms
BigIntegerPow.testPowXS                     avgt    3   4588205708.333 ?  312969172.545   ns/op
BigIntegerPow.testPowXS:gc.alloc.rate       avgt    3         3915.690 ?        266.340  MB/sec
BigIntegerPow.testPowXS:gc.alloc.rate.norm  avgt    3  18839312829.333 ?        337.057    B/op
BigIntegerPow.testPowXS:gc.count            avgt    3          123.000                   counts
BigIntegerPow.testPowXS:gc.time             avgt    3           83.000                       ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2839390637

From duke at openjdk.org  Tue Apr 29 15:55:47 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Apr 2025 15:55:47 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v46]
In-Reply-To: <3SCIKgVUu2jWXZUEtneJW15plxLd327-K7RjQrvIxQI=.bbcb09b5-e1ab-41d3-a777-620b960ffdfc@github.com>
References: 
 <3O57UNZ3SXn29fLVtLJ2hm43d798Vt40EIjcvqbcMus=.e8a5dc7a-bb21-44ec-ad66-c11e0a23456f@github.com>
 <3SCIKgVUu2jWXZUEtneJW15plxLd327-K7RjQrvIxQI=.bbcb09b5-e1ab-41d3-a777-620b960ffdfc@github.com>
Message-ID: <9k2EkkDUEUOrCwHPK_uzuir3h0ucDAcEXvj30njtlG0=.07b6f97b-d94d-4b6f-b916-542a62af5432@github.com>

On Tue, 29 Apr 2025 15:18:35 GMT, Raffaello Giulietti  wrote:

> What went wrong before?

@rgiulietti For some reason, compiling the test with a custom JVM will produce that exception at runtime. It must be compiled with the default JVM, then change the JVM manually and run it with the chosen one.

This is what I get with the current implementation of the master branch:


JMH version: 1.37
VM version: JDK 25-internal, OpenJDK 64-Bit Server VM, 25-internal-adhoc.kali.jdk

Benchmark                                   Mode  Cnt            Score             Error   Units
BigIntegerPow.testPowL                      avgt    3  17080232831.333 ?  3830337700.738   ns/op
BigIntegerPow.testPowL:gc.alloc.rate        avgt    3         1733.162 ?         386.040  MB/sec
BigIntegerPow.testPowL:gc.alloc.rate.norm   avgt    3  31040625648.000 ?         583.799    B/op
BigIntegerPow.testPowL:gc.count             avgt    3          530.000                    counts
BigIntegerPow.testPowL:gc.time              avgt    3          879.000                        ms
BigIntegerPow.testPowM                      avgt    3  12209505388.667 ?  7181143333.594   ns/op
BigIntegerPow.testPowM:gc.alloc.rate        avgt    3         1616.095 ?         932.925  MB/sec
BigIntegerPow.testPowM:gc.alloc.rate.norm   avgt    3  20677114856.000 ?         583.799    B/op
BigIntegerPow.testPowM:gc.count             avgt    3          424.000                    counts
BigIntegerPow.testPowM:gc.time              avgt    3          712.000                        ms
BigIntegerPow.testPowS                      avgt    3  11522214909.000 ?  1929610984.714   ns/op
BigIntegerPow.testPowS:gc.alloc.rate        avgt    3         1701.758 ?         282.671  MB/sec
BigIntegerPow.testPowS:gc.alloc.rate.norm   avgt    3  20562422661.333 ?         891.768    B/op
BigIntegerPow.testPowS:gc.count             avgt    3          350.000                    counts
BigIntegerPow.testPowS:gc.time              avgt    3          597.000                        ms
BigIntegerPow.testPowXL                     avgt    3  19278885432.000 ? 16339410697.856   ns/op
BigIntegerPow.testPowXL:gc.alloc.rate       avgt    3         1739.190 ?        1496.941  MB/sec
BigIntegerPow.testPowXL:gc.alloc.rate.norm  avgt    3  35109921304.000 ?         583.799    B/op
BigIntegerPow.testPowXL:gc.count            avgt    3          637.000                    counts
BigIntegerPow.testPowXL:gc.time             avgt    3         1035.000                        ms
BigIntegerPow.testPowXS                     avgt    3  10361656484.667 ?  1011383535.161   ns/op
BigIntegerPow.testPowXS:gc.alloc.rate       avgt    3         1746.103 ?         168.916  MB/sec
BigIntegerPow.testPowXS:gc.alloc.rate.norm  avgt    3  18974429138.667 ?         337.057    B/op
BigIntegerPow.testPowXS:gc.count            avgt    3          405.000                    counts
BigIntegerPow.testPowXS:gc.time             avgt    3          611.000                        ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2839418316

From duke at openjdk.org  Tue Apr 29 16:06:54 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Apr 2025 16:06:54 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v46]
In-Reply-To: 
References: 
 <3O57UNZ3SXn29fLVtLJ2hm43d798Vt40EIjcvqbcMus=.e8a5dc7a-bb21-44ec-ad66-c11e0a23456f@github.com>
 
Message-ID: 

On Tue, 29 Apr 2025 15:42:56 GMT, Raffaello Giulietti  wrote:

> I don't observe any significant difference on my environment

@rgiulietti Although there could be no significant differences, the method to compute powers of `long`s could be useful, since it is used both by `BigInteger.pow()` and the possible implementation of nth root, so this PR might not be thrown away, or at least not completely.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2839447656

From liach at openjdk.org  Tue Apr 29 16:12:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 16:12:01 GMT
Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to
 class file version [v4]
In-Reply-To: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
Message-ID: 

> Take the class file version to reject flags not yet defined, redefined, or obsoleted. The non-cffv version can return the preview flags when the current runtime is in preview.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Wording updates
 - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
 - Missing since
 - Fix javap causing strictfp tests to fail
 - Further furnish docs
 - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
 - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-cffv-parse
 - Redundant method
 - 8297271: AccessFlag.maskToAccessFlags should be specific to class file version

-------------

Changes: https://git.openjdk.org/jdk/pull/24760/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24760&range=03
  Stats: 233 lines in 14 files changed: 111 ins; 52 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/24760.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24760/head:pull/24760

PR: https://git.openjdk.org/jdk/pull/24760

From duke at openjdk.org  Tue Apr 29 16:15:05 2025
From: duke at openjdk.org (Gautham Krishnan)
Date: Tue, 29 Apr 2025 16:15:05 GMT
Subject: RFR: 8342886: Update MET timezone in TimeZoneNames files [v2]
In-Reply-To: 
References: 
Message-ID: 

> MET timezone entry in TimeZoneNames.java and TimeZoneNames_*.java needs to be updated as MET is alias to Europe/Brussels as per 2024b tzdata changes.
> 
> Also Bug4848242.java needs to be removed as the test expects all euro locale time zones should have the same short names.

Gautham Krishnan has updated the pull request incrementally with one additional commit since the last revision:

  Bringing back  Bug4848242.java
  
  Reverting the change to delete Bug4848242.java  as it is still worth testing, with comments adjusted.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24871/files
  - new: https://git.openjdk.org/jdk/pull/24871/files/4087d825..93ecce79

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24871&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24871&range=00-01

  Stats: 71 lines in 1 file changed: 71 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24871/head:pull/24871

PR: https://git.openjdk.org/jdk/pull/24871

From duke at openjdk.org  Tue Apr 29 16:17:46 2025
From: duke at openjdk.org (Gautham Krishnan)
Date: Tue, 29 Apr 2025 16:17:46 GMT
Subject: RFR: 8342886: Update MET timezone in TimeZoneNames files
In-Reply-To: <8KXAJ9-KCZaXabjNJzt_txzEwml8NsIGSrR87FwG0eU=.a23343f0-cb19-4b40-b3bf-8d2390206fb3@github.com>
References: 
 <8KXAJ9-KCZaXabjNJzt_txzEwml8NsIGSrR87FwG0eU=.a23343f0-cb19-4b40-b3bf-8d2390206fb3@github.com>
Message-ID: 

On Fri, 25 Apr 2025 18:12:32 GMT, Naoto Sato  wrote:

>> MET timezone entry in TimeZoneNames.java and TimeZoneNames_*.java needs to be updated as MET is alias to Europe/Brussels as per 2024b tzdata changes.
>> 
>> Also Bug4848242.java needs to be removed as the test expects all euro locale time zones should have the same short names.
>
> Thanks for the contribution.
>>Also Bug4848242.java needs to be removed as the test expects all euro locale time zones should have the same short names.
> 
> I think this is still worth testing, with comments adjusted (not every euro country, but sampled ones do have the same short names)

@naotoj Thanks for reviewing. Agreed that the Bug4848242.java is still worth testing, with comments adjusted. 
Updated the PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24871#issuecomment-2839487894

From naoto at openjdk.org  Tue Apr 29 16:32:47 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 29 Apr 2025 16:32:47 GMT
Subject: RFR: 8342886: Update MET timezone in TimeZoneNames files [v2]
In-Reply-To: 
References: 
 
Message-ID: <1x8msyRwOle9z9emtfJPUXgF9DqDHIuaw0Ux-m50zmU=.6a4527e1-28ae-4fd4-81a6-b96580fb04b9@github.com>

On Tue, 29 Apr 2025 16:15:05 GMT, Gautham Krishnan  wrote:

>> MET timezone entry in TimeZoneNames.java and TimeZoneNames_*.java needs to be updated as MET is alias to Europe/Brussels as per 2024b tzdata changes.
>> 
>> Also Bug4848242.java needs to be removed as the test expects all euro locale time zones should have the same short names.
>
> Gautham Krishnan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bringing back  Bug4848242.java
>   
>   Reverting the change to delete Bug4848242.java  as it is still worth testing, with comments adjusted.

Thanks for bringing back the test case. Please add the bug id [8342886](https://bugs.openjdk.org/browse/JDK-8342886) in the test header.

test/jdk/sun/util/resources/TimeZone/Bug4848242.java line 31:

> 29:  *         but due to changes in time zone data and locale handling, that is no longer guaranteed.
> 30:  *         This test now verifies that a representative sample of locales (e.g., DE, FR, IT)
> 31:  *         still use the same short names (CET/CEST).

I think German is not in the samples here (it will not return "CET"/"CEST"). Also please use lowercase for the language, eg, fr/it, uppwercased letters are usually for regions.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24871#pullrequestreview-2804305540
PR Review Comment: https://git.openjdk.org/jdk/pull/24871#discussion_r2066932598

From bpb at openjdk.org  Tue Apr 29 16:44:52 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 29 Apr 2025 16:44:52 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value [v4]
In-Reply-To: 
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
 
 
Message-ID: 

On Tue, 29 Apr 2025 05:39:14 GMT, Alan Bateman  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8355444: Add comment tag tp ManyFiles
>
> test/jdk/java/io/FileOutputStream/ManyFiles.java line 33:
> 
>> 31:  * Windows capability it is much simpler to only run it
>> 32:  * on that platform.
>> 33:  * @requires (os.family != "linux")
> 
> I think this comment should be replaced with a clear summary as to why three is a requires. No need to mention Solaris.

Perhaps the `@requires` tag is no longer needed. Without it, this test passed 30 repeats in the CI on both Intel and ARM Linux nodes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24860#discussion_r2066952759

From henryjen at openjdk.org  Tue Apr 29 16:59:49 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 29 Apr 2025 16:59:49 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v4]
In-Reply-To: 
References: 
Message-ID: 

> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/d56eb76c..e38774af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24430/head:pull/24430

PR: https://git.openjdk.org/jdk/pull/24430

From rgiulietti at openjdk.org  Tue Apr 29 17:02:49 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 29 Apr 2025 17:02:49 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v46]
In-Reply-To: <3O57UNZ3SXn29fLVtLJ2hm43d798Vt40EIjcvqbcMus=.e8a5dc7a-bb21-44ec-ad66-c11e0a23456f@github.com>
References: 
 <3O57UNZ3SXn29fLVtLJ2hm43d798Vt40EIjcvqbcMus=.e8a5dc7a-bb21-44ec-ad66-c11e0a23456f@github.com>
Message-ID: 

On Tue, 29 Apr 2025 15:10:10 GMT, fabioromano1  wrote:

>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>
> fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adjust the type of operand
>  - Use a more loose formula to do range check
>    
>    Use a more loose formula to do range check, in order not to exclude a priori values that may be inside the supported range

I must have screwed up something in my previous benchmarks, probably when copying the master branch (current) `BigInteger` into the PR branch for the "before" figures.

Here's indeed a more favorable picture (but certainly not a 50% enhancement in allocation rate).
I obtain comparable results with more iterations (`make test TEST="micro:java.math.BigIntegerPow" MICRO="WARMUP_ITER=3;ITER=3;OPTIONS=-prof gc"`).

I'll delete my previous misleading results.
Sorry for the noise.

macOS 15.4.1 / M1 Pro / 32 GiB / java 25-internal

_before_

Benchmark                                   Mode  Cnt            Score           Error   Units
BigIntegerPow.testPowL                      avgt    3   7828857180.333 ? 723831405.464   ns/op
BigIntegerPow.testPowL:gc.alloc.rate        avgt    3         4766.633 ?       440.607  MB/sec
BigIntegerPow.testPowL:gc.alloc.rate.norm   avgt    3  39130646080.000 ?         0.001    B/op
BigIntegerPow.testPowL:gc.count             avgt    3          260.000                  counts
BigIntegerPow.testPowL:gc.time              avgt    3          190.000                      ms
BigIntegerPow.testPowM                      avgt    3   7784905013.667 ? 751070238.685   ns/op
BigIntegerPow.testPowM:gc.alloc.rate        avgt    3         4737.671 ?       455.843  MB/sec
BigIntegerPow.testPowM:gc.alloc.rate.norm   avgt    3  38674111834.667 ?       337.057    B/op
BigIntegerPow.testPowM:gc.count             avgt    3          257.000                  counts
BigIntegerPow.testPowM:gc.time              avgt    3          192.000                      ms
BigIntegerPow.testPowS                      avgt    3   7615946041.333 ? 505408224.968   ns/op
BigIntegerPow.testPowS:gc.alloc.rate        avgt    3         4622.726 ?       306.660  MB/sec
BigIntegerPow.testPowS:gc.alloc.rate.norm   avgt    3  36917399656.000 ?         0.001    B/op
BigIntegerPow.testPowS:gc.count             avgt    3          246.000                  counts
BigIntegerPow.testPowS:gc.time              avgt    3          184.000                      ms
BigIntegerPow.testPowXL                     avgt    3   7806063305.667 ? 841981680.300   ns/op
BigIntegerPow.testPowXL:gc.alloc.rate       avgt    3         4795.153 ?       515.480  MB/sec
BigIntegerPow.testPowXL:gc.alloc.rate.norm  avgt    3  39249581269.333 ?       337.057    B/op
BigIntegerPow.testPowXL:gc.count            avgt    3          261.000                  counts
BigIntegerPow.testPowXL:gc.time             avgt    3          194.000                      ms
BigIntegerPow.testPowXS                     avgt    3   6613315027.667 ? 330610647.532   ns/op
BigIntegerPow.testPowXS:gc.alloc.rate       avgt    3         4254.182 ?       212.492  MB/sec
BigIntegerPow.testPowXS:gc.alloc.rate.norm  avgt    3  29501518834.667 ?       337.057    B/op
BigIntegerPow.testPowXS:gc.count            avgt    3          197.000                  counts
BigIntegerPow.testPowXS:gc.time             avgt    3          147.000                      ms


_after_

Benchmark                                   Mode  Cnt            Score           Error   Units
BigIntegerPow.testPowL                      avgt    3   7366544708.333 ? 829671998.680   ns/op
BigIntegerPow.testPowL:gc.alloc.rate        avgt    3         4018.527 ?       452.726  MB/sec
BigIntegerPow.testPowL:gc.alloc.rate.norm   avgt    3  31040625690.667 ?       337.057    B/op
BigIntegerPow.testPowL:gc.count             avgt    3          201.000                  counts
BigIntegerPow.testPowL:gc.time              avgt    3          138.000                      ms
BigIntegerPow.testPowM                      avgt    3   5185182639.000 ? 115159325.868   ns/op
BigIntegerPow.testPowM:gc.alloc.rate        avgt    3         3784.654 ?       158.695  MB/sec
BigIntegerPow.testPowM:gc.alloc.rate.norm   avgt    3  20578167389.333 ? 439891534.193    B/op
BigIntegerPow.testPowM:gc.count             avgt    3          135.000                  counts
BigIntegerPow.testPowM:gc.time              avgt    3           89.000                      ms
BigIntegerPow.testPowS                      avgt    3   5129524208.333 ? 622597661.429   ns/op
BigIntegerPow.testPowS:gc.alloc.rate        avgt    3         3807.115 ?       460.287  MB/sec
BigIntegerPow.testPowS:gc.alloc.rate.norm   avgt    3  20477396202.667 ?       337.057    B/op
BigIntegerPow.testPowS:gc.count             avgt    3          135.000                  counts
BigIntegerPow.testPowS:gc.time              avgt    3           90.000                      ms
BigIntegerPow.testPowXL                     avgt    3   8098242069.667 ? 905979832.443   ns/op
BigIntegerPow.testPowXL:gc.alloc.rate       avgt    3         4134.655 ?       462.498  MB/sec
BigIntegerPow.testPowXL:gc.alloc.rate.norm  avgt    3  35109921325.333 ?       337.057    B/op
BigIntegerPow.testPowXL:gc.count            avgt    3          231.000                  counts
BigIntegerPow.testPowXL:gc.time             avgt    3          159.000                      ms
BigIntegerPow.testPowXS                     avgt    3   4587145069.333 ? 537879394.284   ns/op
BigIntegerPow.testPowXS:gc.alloc.rate       avgt    3         3916.668 ?       458.061  MB/sec
BigIntegerPow.testPowXS:gc.alloc.rate.norm  avgt    3  18839312829.333 ?       337.057    B/op
BigIntegerPow.testPowXS:gc.count            avgt    3          123.000                  counts
BigIntegerPow.testPowXS:gc.time             avgt    3           82.000                      ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2839600648

From duke at openjdk.org  Tue Apr 29 17:06:30 2025
From: duke at openjdk.org (Gautham Krishnan)
Date: Tue, 29 Apr 2025 17:06:30 GMT
Subject: RFR: 8342886: Update MET timezone in TimeZoneNames files [v3]
In-Reply-To: 
References: 
Message-ID: <5JFTqSSyncgkeXZHFDxAcL15wOzfX6B_ygn-8ioAtXc=.e3cb7222-bf83-435a-b34c-7060c74c15ac@github.com>

> MET timezone entry in TimeZoneNames.java and TimeZoneNames_*.java needs to be updated as MET is alias to Europe/Brussels as per 2024b tzdata changes.
> 
> Also Bug4848242.java needs to be removed as the test expects all euro locale time zones should have the same short names.

Gautham Krishnan has updated the pull request incrementally with one additional commit since the last revision:

  Updating comment in Bug4848242.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24871/files
  - new: https://git.openjdk.org/jdk/pull/24871/files/93ecce79..56bc5cdd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24871&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24871&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24871/head:pull/24871

PR: https://git.openjdk.org/jdk/pull/24871

From duke at openjdk.org  Tue Apr 29 17:06:30 2025
From: duke at openjdk.org (Gautham Krishnan)
Date: Tue, 29 Apr 2025 17:06:30 GMT
Subject: RFR: 8342886: Update MET timezone in TimeZoneNames files
In-Reply-To: <8KXAJ9-KCZaXabjNJzt_txzEwml8NsIGSrR87FwG0eU=.a23343f0-cb19-4b40-b3bf-8d2390206fb3@github.com>
References: 
 <8KXAJ9-KCZaXabjNJzt_txzEwml8NsIGSrR87FwG0eU=.a23343f0-cb19-4b40-b3bf-8d2390206fb3@github.com>
Message-ID: 

On Fri, 25 Apr 2025 18:12:32 GMT, Naoto Sato  wrote:

>> MET timezone entry in TimeZoneNames.java and TimeZoneNames_*.java needs to be updated as MET is alias to Europe/Brussels as per 2024b tzdata changes.
>> 
>> Also Bug4848242.java needs to be removed as the test expects all euro locale time zones should have the same short names.
>
> Thanks for the contribution.
>>Also Bug4848242.java needs to be removed as the test expects all euro locale time zones should have the same short names.
> 
> I think this is still worth testing, with comments adjusted (not every euro country, but sampled ones do have the same short names)

@naotoj updated. Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24871#issuecomment-2839606853

From duke at openjdk.org  Tue Apr 29 17:08:21 2025
From: duke at openjdk.org (kabutz)
Date: Tue, 29 Apr 2025 17:08:21 GMT
Subject: RFR: 8355938: Addressed rare lost unpark bug 8074773 by pre-loading
 LockSupport.class
Message-ID: 

In 2015, Google discovered a rare disastrous classloading bug in first call to LockSupport.park() that occurred in the AppClassLoader using the Java 7 ConcurrentHashMap, which used ReentrantLock for the synchronization.

Since then, the recommended fix for this bug seems to be this code snippet in any class that directly calls LockSupport.park():


static {
    // Prevent rare disastrous classloading in first call to LockSupport.park.
    // See: https://bugs.openjdk.java.net/browse/JDK-8074773
    Class ensureLoaded = LockSupport.class;
}


Since the bug was logged, we have seen new classes in the JDK that call LockSupport.park(), but that do not have this code snippet. For example:

sun.nio.ch.Poller
jdk.internal.misc.ThreadFlock
java.util.concurrent.ThreadPerTaskExecutor

It should probably also be in:

java.util.concurrent.Exchanger

Considering how hard this bug is to detect and solve, it would probably be safer to add the code snippet into these newer classes.

-------------

Commit messages:
 - Addressed rare lost unpark bug 8074773 by pre-loading LockSupport.class

Changes: https://git.openjdk.org/jdk/pull/24952/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24952&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355938
  Stats: 22 lines in 4 files changed: 21 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24952.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24952/head:pull/24952

PR: https://git.openjdk.org/jdk/pull/24952

From rgiulietti at openjdk.org  Tue Apr 29 17:11:50 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 29 Apr 2025 17:11:50 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v46]
In-Reply-To: 
References: 
 <3O57UNZ3SXn29fLVtLJ2hm43d798Vt40EIjcvqbcMus=.e8a5dc7a-bb21-44ec-ad66-c11e0a23456f@github.com>
 
Message-ID: <_kqnw2WmnM7r3b5xTCBX8T5ic1-ARhw6N8jwvELo8rY=.9f57461d-0db5-4cd1-8b85-50fea2794de5@github.com>

On Tue, 29 Apr 2025 17:00:25 GMT, Raffaello Giulietti  wrote:

>> fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Adjust the type of operand
>>  - Use a more loose formula to do range check
>>    
>>    Use a more loose formula to do range check, in order not to exclude a priori values that may be inside the supported range
>
> I must have screwed up something in my previous benchmarks, probably when copying the master branch (current) `BigInteger` into the PR branch for the "before" figures.
> 
> Here's indeed a more favorable picture (but certainly not a 50% enhancement in allocation rate).
> I obtain comparable results with more iterations (`make test TEST="micro:java.math.BigIntegerPow" MICRO="WARMUP_ITER=3;ITER=3;OPTIONS=-prof gc"`).
> 
> I'll delete my previous misleading results.
> Sorry for the noise.
> 
> macOS 15.4.1 / M1 Pro / 32 GiB / java 25-internal
> 
> _before_
> 
> Benchmark                                   Mode  Cnt            Score           Error   Units
> BigIntegerPow.testPowL                      avgt    3   7828857180.333 ? 723831405.464   ns/op
> BigIntegerPow.testPowL:gc.alloc.rate        avgt    3         4766.633 ?       440.607  MB/sec
> BigIntegerPow.testPowL:gc.alloc.rate.norm   avgt    3  39130646080.000 ?         0.001    B/op
> BigIntegerPow.testPowL:gc.count             avgt    3          260.000                  counts
> BigIntegerPow.testPowL:gc.time              avgt    3          190.000                      ms
> BigIntegerPow.testPowM                      avgt    3   7784905013.667 ? 751070238.685   ns/op
> BigIntegerPow.testPowM:gc.alloc.rate        avgt    3         4737.671 ?       455.843  MB/sec
> BigIntegerPow.testPowM:gc.alloc.rate.norm   avgt    3  38674111834.667 ?       337.057    B/op
> BigIntegerPow.testPowM:gc.count             avgt    3          257.000                  counts
> BigIntegerPow.testPowM:gc.time              avgt    3          192.000                      ms
> BigIntegerPow.testPowS                      avgt    3   7615946041.333 ? 505408224.968   ns/op
> BigIntegerPow.testPowS:gc.alloc.rate        avgt    3         4622.726 ?       306.660  MB/sec
> BigIntegerPow.testPowS:gc.alloc.rate.norm   avgt    3  36917399656.000 ?         0.001    B/op
> BigIntegerPow.testPowS:gc.count             avgt    3          246.000                  counts
> BigIntegerPow.testPowS:gc.time              avgt    3          184.000                      ms
> BigIntegerPow.testPowXL                     avgt    3   7806063305.667 ? 841981680.300   ns/op
> BigIntegerPow.testPowXL:gc.alloc.rate       avgt    3         4795.153 ?       515.480  MB/sec
> BigIntegerPow.testPowXL:gc.alloc.rate.norm  avgt    3  39249581269.333 ?       337.057    B/op
> BigIntegerPow.testPowXL:gc.count            avgt    3          261.000                  counts
> BigIntegerPow.testPowXL:gc.time             avgt    3      ...

> @rgiulietti Although there could be no significant differences, the method to compute powers of longs could be useful, since it is used both by BigInteger.pow() and the possible implementation of nth root, so this PR might not be thrown away, or at least not completely.

Please keep going...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2839626328

From liach at openjdk.org  Tue Apr 29 17:12:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 17:12:57 GMT
Subject: RFR: 8341275: Explicit counter support for Code attribute building
 [v2]
In-Reply-To: <0QEX0NA3qOGsRadwDcp42BhyOeZl09677eskI00x7Lo=.bd667709-7c30-4489-8013-411326e63813@github.com>
References: 
 <0QEX0NA3qOGsRadwDcp42BhyOeZl09677eskI00x7Lo=.bd667709-7c30-4489-8013-411326e63813@github.com>
Message-ID: 

On Sun, 27 Apr 2025 03:38:35 GMT, Chen Liang  wrote:

>> Internal explicit counter support for Code max_stack and max_locals has been already added in #24807. Since that example works well, we may consider opening this functionality up to general users under strict restrictions.
>> 
>> This is an advanced API; thus, I chose a more complex name `withExplicitStackAndLocals` that discourages accidental use, and indicates the exact order of stack and locals arguments. For integrity, the argument checks are unconditional. And this is also barred behind `DROP_STACK_MAPS` advanced option.
>> 
>> I have enhanced the tests with a `CodeBuilderType` utility to test all types of code builders; it is already effective at increasing coverage in some of our existing tests that only cover DirectCodeBuilder, and simplify other tests. It is particularly helpful for my new `BuilderExplicitMaxsTest`.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust indents

Thanks, withdrawing this for now. A better approach may be to optimize StackCounter when a SMT is present.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24903#issuecomment-2839627091

From liach at openjdk.org  Tue Apr 29 17:12:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 17:12:58 GMT
Subject: Withdrawn: 8341275: Explicit counter support for Code attribute
 building
In-Reply-To: 
References: 
Message-ID: <8nUFQnFhBPSvqYSKnHuBz8vryFP4Xa3OSEaD7Ls-hl4=.032ca982-9f8d-4c06-9e81-8a6cd1cf1d06@github.com>

On Sun, 27 Apr 2025 02:04:30 GMT, Chen Liang  wrote:

> Internal explicit counter support for Code max_stack and max_locals has been already added in #24807. Since that example works well, we may consider opening this functionality up to general users under strict restrictions.
> 
> This is an advanced API; thus, I chose a more complex name `withExplicitStackAndLocals` that discourages accidental use, and indicates the exact order of stack and locals arguments. For integrity, the argument checks are unconditional. And this is also barred behind `DROP_STACK_MAPS` advanced option.
> 
> I have enhanced the tests with a `CodeBuilderType` utility to test all types of code builders; it is already effective at increasing coverage in some of our existing tests that only cover DirectCodeBuilder, and simplify other tests. It is particularly helpful for my new `BuilderExplicitMaxsTest`.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24903

From alanb at openjdk.org  Tue Apr 29 17:15:44 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Apr 2025 17:15:44 GMT
Subject: RFR: 8355938: Addressed rare lost unpark bug 8074773 by
 pre-loading LockSupport.class
In-Reply-To: 
References: 
Message-ID: 

On Tue, 29 Apr 2025 17:02:38 GMT, kabutz  wrote:

> In 2015, Google discovered a rare disastrous classloading bug in first call to LockSupport.park() that occurred in the AppClassLoader using the Java 7 ConcurrentHashMap, which used ReentrantLock for the synchronization.
> 
> Since then, the recommended fix for this bug seems to be this code snippet in any class that directly calls LockSupport.park():
> 
> 
> static {
>     // Prevent rare disastrous classloading in first call to LockSupport.park.
>     // See: https://bugs.openjdk.java.net/browse/JDK-8074773
>     Class ensureLoaded = LockSupport.class;
> }
> 
> 
> Since the bug was logged, we have seen new classes in the JDK that call LockSupport.park(), but that do not have this code snippet. For example:
> 
> sun.nio.ch.Poller
> jdk.internal.misc.ThreadFlock
> java.util.concurrent.ThreadPerTaskExecutor
> 
> It should probably also be in:
> 
> java.util.concurrent.Exchanger
> 
> Considering how hard this bug is to detect and solve, it would probably be safer to add the code snippet into these newer classes.

Might be a bit premature to change these classes. I think the starting point is to page in the issue from 2015 so there is a clearer picture of where the parking permit is consumed. Was it always CHM used by parallel capable class loaders? It might be that we should preload LockSupport in initPhase3 but I think it requires more details on the original issue before doing anything.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24952#issuecomment-2839633607

From rgiulietti at openjdk.org  Tue Apr 29 17:16:45 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 29 Apr 2025 17:16:45 GMT
Subject: RFR: 8351000: StringBuilder getChar and putChar robustness
In-Reply-To: 
References: 
Message-ID: 

On Tue, 29 Apr 2025 14:10:30 GMT, Roger Riggs  wrote:

> Improve StringBuilder getChar and putChar robustness with racy updates to StringBuilder. 
> Test racing threads with append, insert, and reading characters.

Looks fine.
Thanks @RogerRiggs

-------------

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24951#pullrequestreview-2804413875

From naoto at openjdk.org  Tue Apr 29 17:39:46 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 29 Apr 2025 17:39:46 GMT
Subject: RFR: 8342886: Update MET timezone in TimeZoneNames files [v3]
In-Reply-To: <5JFTqSSyncgkeXZHFDxAcL15wOzfX6B_ygn-8ioAtXc=.e3cb7222-bf83-435a-b34c-7060c74c15ac@github.com>
References: 
 <5JFTqSSyncgkeXZHFDxAcL15wOzfX6B_ygn-8ioAtXc=.e3cb7222-bf83-435a-b34c-7060c74c15ac@github.com>
Message-ID: 

On Tue, 29 Apr 2025 17:06:30 GMT, Gautham Krishnan  wrote:

>> MET timezone entry in TimeZoneNames.java and TimeZoneNames_*.java needs to be updated as MET is alias to Europe/Brussels as per 2024b tzdata changes.
>> 
>> Also Bug4848242.java needs to be removed as the test expects all euro locale time zones should have the same short names.
>
> Gautham Krishnan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating comment in Bug4848242.java

You'll need to append "8342886" to the `@bug` tag

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24871#issuecomment-2839695517

From rgiulietti at openjdk.org  Tue Apr 29 17:39:51 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 29 Apr 2025 17:39:51 GMT
Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 9 Jan 2025 10:55:16 GMT, Raffaello Giulietti  wrote:

>> See the JBS bug for some details.
>
> Raffaello Giulietti 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' into 8343829
>  - Redacted comments.
>  - Merge branch 'master' into 8343829
>  - Minors in comments.
>  - Removed repeated comment.
>  - Refactoring some code and comments.
>  - 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal

Comment added...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22737#issuecomment-2839697075

From duke at openjdk.org  Tue Apr 29 17:50:05 2025
From: duke at openjdk.org (Gautham Krishnan)
Date: Tue, 29 Apr 2025 17:50:05 GMT
Subject: RFR: 8342886: Update MET timezone in TimeZoneNames files [v4]
In-Reply-To: 
References: 
Message-ID: 

> MET timezone entry in TimeZoneNames.java and TimeZoneNames_*.java needs to be updated as MET is alias to Europe/Brussels as per 2024b tzdata changes.
> 
> Also Bug4848242.java needs to be removed as the test expects all euro locale time zones should have the same short names.

Gautham Krishnan has updated the pull request incrementally with one additional commit since the last revision:

  Updating @bug tag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24871/files
  - new: https://git.openjdk.org/jdk/pull/24871/files/56bc5cdd..2c008179

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24871&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24871&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24871/head:pull/24871

PR: https://git.openjdk.org/jdk/pull/24871

From duke at openjdk.org  Tue Apr 29 17:50:05 2025
From: duke at openjdk.org (Gautham Krishnan)
Date: Tue, 29 Apr 2025 17:50:05 GMT
Subject: RFR: 8342886: Update MET timezone in TimeZoneNames files [v3]
In-Reply-To: 
References: 
 <5JFTqSSyncgkeXZHFDxAcL15wOzfX6B_ygn-8ioAtXc=.e3cb7222-bf83-435a-b34c-7060c74c15ac@github.com>
 
Message-ID: 

On Tue, 29 Apr 2025 17:36:26 GMT, Naoto Sato  wrote:

>> Gautham Krishnan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating comment in Bug4848242.java
>
> You'll need to append "8342886" to the `@bug` tag

@naotoj updated. Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24871#issuecomment-2839718245

From naoto at openjdk.org  Tue Apr 29 18:03:47 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 29 Apr 2025 18:03:47 GMT
Subject: RFR: 8342886: Update MET timezone in TimeZoneNames files [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 17:50:05 GMT, Gautham Krishnan  wrote:

>> MET timezone entry in TimeZoneNames.java and TimeZoneNames_*.java needs to be updated as MET is alias to Europe/Brussels as per 2024b tzdata changes.
>> 
>> Also Bug4848242.java needs to be removed as the test expects all euro locale time zones should have the same short names.
>
> Gautham Krishnan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating @bug tag

test/jdk/sun/util/resources/TimeZone/Bug4848242.java line 26:

> 24: /*
> 25:  *@test
> 26:  *@bug 8342886

The bug id needs to be appended

Suggestion:

 *@bug 4848242 8342886

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24871#discussion_r2067070677

From roger.riggs at oracle.com  Tue Apr 29 18:07:16 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 29 Apr 2025 14:07:16 -0400
Subject: Runtime.exec and SIGPIPE + SIG_IGN
In-Reply-To: 
References: 
 
 
Message-ID: <5c8db67c-7af4-4119-a769-735376aae8bb@oracle.com>

Hi Thomas, Archie,

Generally, I would agree that a bit more cleanup/resetting of the signal 
state makes sense.
There is general unease about changing this kind of global state that 
has been stable for a long time.
An application that expects to change operating system state before 
calling exec and expecting it to be retained/passed to the child is 
expecting too much.

A change here should also be reviewed by Hotspot, signals are a 
sensitive area for them too.

Regards, Roger

On 4/29/25 10:55 AM, Thomas St?fe wrote:
> Hi Archie!
>
> On Tue, Apr 29, 2025 at 4:17?PM Archie Cobbs  
> wrote:
>
>     This reminds me of a bug I saw once decades ago: the JVM was not
>     setting the close-on-exec flag on new file descriptors, so child
>     processes were receiving copies of "leaked" file descriptors and
>     keeping them open indefinitely, causing the system to eventually
>     running out of file descriptors and crash.
>
>
> I remember. We fixed that in jspawnhelper.
>
>     The moral of that story was that control of the "process
>     environment" of a new process (i.e., which file descriptors are
>     open, signal handlers installed, etc.) created via the usual
>     fork/exec sequence clearly belongs to the bit of code that is
>     spawning that process for whatever reason: any inheritable part of
>     the process environment that the JVM might mess around with must
>     be reset before spawning child processes.
>
>
> Agreed.
>
>     So if some native code wants to configure SIGPIPE for SIG_IGN and
>     then fork/exec a child process that inherits that setting, then fine.
>
>     But if the JVM itself is doing its fork/exec for some unrelated
>     purpose (e.g., Runtime.exec()), it has the right and
>     responsibility to clean up the environment that the child process
>     is going to inherit to protect it from any changes due to the JVM
>     process, including native code.
>
>     So it seems like there are two possible bugs here:
>
>     1. Some JNI code links in a library that changes the (global)
>     setting for SIGPIPE. Is that allowed by the JNI specification?
>     Does the specification even say? It seems like this is not really
>     kosher, but anyway it happens to work by coincidence because
>     SIG_IGN and javaSignalHandler do the same thing (i.e., discard the
>     signal).
>
>
> To my knowledge the JNI spec says nothing about signals.
>
>     2. The JVM is not completely scrubbing the child's process
>     environment when it spawns a new process as it should: All signal
>     handlers should be reset to their default values (unless there is
>     some JVM-specific reason to set them differently).
>
>     It seems like #2 is a valid bug or at least a valid improvement,
>     and whether #1 is a bug depends on what you believe JNI libraries
>     are officially allowed to do.
>
>
> I agree. Note that we also have a slight inconsistency depending on 
> the order of third-party signal handler installation:
>
> 1) In a scenario like the one I described we start java, it installs 
> the SIGPIPE handler, which then gets preplaced by the third-party lib 
> with SIG_IGN, resulting in child processes running with SIG_IGN for 
> SIGPIPE.
> 2) If, however,r the libjvm.so gets embedded into a custom launcher, 
> which already had set SIG_IGN for SIGPIPE, the JVM will replace that 
> handler with its own, resulting in child processes running with SIG_DFL.
>
> This seems a bit arbitrary to me and seems to support the view that 
> this behavior is not intended.
>
>     -Archie
>
>     On Tue, Apr 29, 2025 at 4:05?AM Thomas St?fe
>      wrote:
>
>         Hi,
>
>         I would like to gauge opinions on whether the following
>         scenario is a bug to fix or whether to accept it as standard
>         behavior.
>
>         ---
>
>         A customer has the following problem:
>
>         - The JVM invokes a third-party JNI library that sets the
>         signal disposition of SIGPIPE to SIG_IGN (Boo! in this case,
>         it is the FIPS nspr library, which does this unconditionally.)
>         - The JVM then spawns child processes
>         - All child processes now ignore SIGPIPE, which leads to
>         failures in automation scripts
>
>         I was surprised. I always assumed the signal disposition of
>         all signals would be reset to SIG_DFL when exec'ing. However,
>         seems I was wrong when it came to SIG_IGN. Posix documents for
>         execve() states [1]:
>
>         1) " Signals set to the default action (SIG_DFL) in the
>         calling process image shall be set to the default action in
>         the new process image."
>
>         and
>
>         2) "Except for SIGCHLD, signals set to be ignored (SIG_IGN) by
>         the calling process image shall be set to be ignored by the
>         new process image."
>
>         and
>
>         3) "Signals set to be caught by the calling process image
>         shall be set to the default action in the new process image
>         (see //
>         )."
>
>         (2) and (3) are the interesting parts. (2) means that if the
>         parent process ignores SIGPIPE, child processes will also
>         ignore SIGPIPE. (3) means that if the parent process has a
>         custom handler installed for SIGPIPE, child processes will be
>         started with SIG_DFL (default action) for SIGPIPE. The default
>         action for SIGPIPE is "terminate process".
>
>         The libjvm handles SIGPIPE. We install our
>         `javaSignalHandler`. We do this to eat up and ignore SIGPIPE.
>         That we "manually" ignore the signal beside the point here -
>         what counts is that we set a custom signal handler for
>         SIGPIPE. Therefore, on execve, we behave according to rule (3)
>         and start the child with SIG_DFL as SIGPIPE disposition. As it
>         should be.
>
>         If third-party code sets the handler to SIG_IGN as in this
>         example, exeve will behave according to rule (2) and the child
>         will start with SIG_IGN as SIGPIPE disposition.
>
>         The libjig can be used to workaround this scenario, but I
>         wonder if that is more of an accident. The libjsig.so will
>         preserve the JVM's SIGPIPE handler even if third-party code
>         attempts to set it to SIG_IGN. That means that exeve still
>         behaves according to rule (2): sets child's SIGPIPE
>         disposition to SIG_DFL.
>
>         ----
>
>         But I wonder whether this should not be considered a bug to
>         fix regardless of the jsig.so workaround? In jspawnhelper, we
>         clean the environment from various effects when exec'ing;
>         among other things, we reset the signal block mask for the
>         process. The "ignore" state of processes could be considered
>         along the same line. We could reset all signal handlers to
>         SIG_DFL before execing the child.
>
>         I know that this area is super-tricky and problems are
>         notoriously difficult to analyze; we should therefore be
>         extremely careful not to break downward compatibility. Still,
>         what do people think? Should be fix this in jspawnhelper?
>
>         Thanks, Thomas
>
>         (cc'ing Roger)
>
>         [1]
>         https://pubs.opengroup.org/onlinepubs/009695399/functions/exec.html
>         
>
>
>
>     -- 
>     Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From shade at openjdk.org  Tue Apr 29 18:10:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 29 Apr 2025 18:10:56 GMT
Subject: RFR: 8342283: CDS cannot handle a large number of classes [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Apr 2025 09:20:38 GMT, Aleksey Shipilev  wrote:

>> CDS cannot handle large number of classes, because `ClassLoader` data structures get too large for CDS archival. The new test captures such an occasion. We do `clear()`-s, but that is not enough to trim the backing storages for the affected collections.
>> 
>> In contrast with previous attempts to fix this (https://github.com/openjdk/jdk/pull/21797 and my VM-side field overwrite), we can just reinitialize the fields using `Unsafe`, which bypasses normal `final` field write restriction. `ClassLoader` already does a similar thing nearby! This allows us to stay fully in Java, and makes the patch fairly straightforward.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, new test reliably fails without the fix, passes with it
>>  - [x] Linux x86_64 server fastdebug, `runtime/cds`
>
> 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:
> 
>  - Minor touchup
>  - Merge branch 'master' into JDK-8342283-cds-many-classes
>  - Adjust TEST.groups
>  - Fix

Testing is green. I am integrating.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24877#issuecomment-2839760107

From shade at openjdk.org  Tue Apr 29 18:10:57 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 29 Apr 2025 18:10:57 GMT
Subject: Integrated: 8342283: CDS cannot handle a large number of classes
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Apr 2025 14:49:37 GMT, Aleksey Shipilev  wrote:

> CDS cannot handle large number of classes, because `ClassLoader` data structures get too large for CDS archival. The new test captures such an occasion. We do `clear()`-s, but that is not enough to trim the backing storages for the affected collections.
> 
> In contrast with previous attempts to fix this (https://github.com/openjdk/jdk/pull/21797 and my VM-side field overwrite), we can just reinitialize the fields using `Unsafe`, which bypasses normal `final` field write restriction. `ClassLoader` already does a similar thing nearby! This allows us to stay fully in Java, and makes the patch fairly straightforward.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, new test reliably fails without the fix, passes with it
>  - [x] Linux x86_64 server fastdebug, `runtime/cds`

This pull request has now been integrated.

Changeset: ead67574
Author:    Aleksey Shipilev 
URL:       https://git.openjdk.org/jdk/commit/ead6757486fb58f35f6e93b691519673bca1a549
Stats:     166 lines in 4 files changed: 156 ins; 2 del; 8 mod

8342283: CDS cannot handle a large number of classes

Co-authored-by: Ioi Lam 
Reviewed-by: iklam, lmesnik, ccheung

-------------

PR: https://git.openjdk.org/jdk/pull/24877

From duke at openjdk.org  Tue Apr 29 18:11:05 2025
From: duke at openjdk.org (Gautham Krishnan)
Date: Tue, 29 Apr 2025 18:11:05 GMT
Subject: RFR: 8342886: Update MET timezone in TimeZoneNames files [v5]
In-Reply-To: 
References: 
Message-ID: 

> MET timezone entry in TimeZoneNames.java and TimeZoneNames_*.java needs to be updated as MET is alias to Europe/Brussels as per 2024b tzdata changes.
> 
> Also Bug4848242.java needs to be removed as the test expects all euro locale time zones should have the same short names.

Gautham Krishnan has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/sun/util/resources/TimeZone/Bug4848242.java
  
  Co-authored-by: Naoto Sato 

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24871/files
  - new: https://git.openjdk.org/jdk/pull/24871/files/2c008179..30e2c54a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24871&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24871&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24871/head:pull/24871

PR: https://git.openjdk.org/jdk/pull/24871

From bpb at openjdk.org  Tue Apr 29 18:31:37 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 29 Apr 2025 18:31:37 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value [v5]
In-Reply-To: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
Message-ID: 

> Use the `@requires` tag instead of obtaining the operating system name from the `os.name` property and then exiting if the test is not run on that operating system.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8355444: Simplify comment about requires tag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24860/files
  - new: https://git.openjdk.org/jdk/pull/24860/files/fb9f0c5c..4cee3c2b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24860&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24860&range=03-04

  Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24860/head:pull/24860

PR: https://git.openjdk.org/jdk/pull/24860

From bpb at openjdk.org  Tue Apr 29 18:31:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 29 Apr 2025 18:31:38 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value [v4]
In-Reply-To: 
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
 
 
 
Message-ID: 

On Tue, 29 Apr 2025 16:42:26 GMT, Brian Burkhalter  wrote:

>> test/jdk/java/io/FileOutputStream/ManyFiles.java line 33:
>> 
>>> 31:  * Windows capability it is much simpler to only run it
>>> 32:  * on that platform.
>>> 33:  * @requires (os.family != "linux")
>> 
>> I think this comment should be replaced with a clear summary as to why three is a requires. No need to mention Solaris.
>
> Perhaps the `@requires` tag is no longer needed. Without it, this test passed 30 repeats in the CI on both Intel and ARM Linux nodes.

Comment simplified in 4cee3c2.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24860#discussion_r2067114901

From duke at openjdk.org  Tue Apr 29 18:31:57 2025
From: duke at openjdk.org (Christoph)
Date: Tue, 29 Apr 2025 18:31:57 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev  wrote:

> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
> - This change is for macOS only.
> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.

This is unfortunate. However, then how do I add content to the app image before? 
Our current workaround is to build an app-image only and then manually pack it but this misses the dmg background images and install instructions etc

https://github.com/JabRef/jabref/blob/97aaab58e3ab543a0f50097ee59e52504d99c786/.github/workflows/deployment.yml#L167-L178

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2839847379

From duke at openjdk.org  Tue Apr 29 18:34:44 2025
From: duke at openjdk.org (kabutz)
Date: Tue, 29 Apr 2025 18:34:44 GMT
Subject: RFR: 8355938: Addressed rare lost unpark bug 8074773 by
 pre-loading LockSupport.class
In-Reply-To: 
References: 
Message-ID: 

On Tue, 29 Apr 2025 17:02:38 GMT, kabutz  wrote:

> In 2015, Google discovered a rare disastrous classloading bug in first call to LockSupport.park() that occurred in the AppClassLoader using the Java 7 ConcurrentHashMap, which used ReentrantLock for the synchronization.
> 
> Since then, the recommended fix for this bug seems to be this code snippet in any class that directly calls LockSupport.park():
> 
> 
> static {
>     // Prevent rare disastrous classloading in first call to LockSupport.park.
>     // See: https://bugs.openjdk.java.net/browse/JDK-8074773
>     Class ensureLoaded = LockSupport.class;
> }
> 
> 
> Since the bug was logged, we have seen new classes in the JDK that call LockSupport.park(), but that do not have this code snippet. For example:
> 
> sun.nio.ch.Poller
> jdk.internal.misc.ThreadFlock
> java.util.concurrent.ThreadPerTaskExecutor
> 
> It should probably also be in:
> 
> java.util.concurrent.Exchanger
> 
> Considering how hard this bug is to detect and solve, it would probably be safer to add the code snippet into these newer classes.

What is the potential downside of adding the static block to make sure the class is loaded?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24952#issuecomment-2839855294

From duke at openjdk.org  Tue Apr 29 18:43:46 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 29 Apr 2025 18:43:46 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v8]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Sun, 27 Apr 2025 17:29:32 GMT, Chen Liang  wrote:

>> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 722:
>> 
>>> 720:     }
>>> 721: 
>>> 722:     private static final class AccessFlagSet extends AbstractSet {
>> 
>> This?should probably also?define the?spliterator method:
>> 
>> @Override
>> public Spliterator spliterator() {
>> 	return Spliterators.spliterator(
>> 		this,
>> 		Spliterator.DISTINCT	| Spliterator.ORDERED	| Spliterator.SIZED
>> 		| Spliterator.NONNULL	| Spliterator.IMMUTABLE	| Spliterator.SUBSIZED
>> 	);
>> }
>
> Hmm, I intentionally avoided implementing spliterator because there are too many opportunities to optimize - a fully optimized Spliterator implementaton should split an int mask. Can we do that in another patch? I need to check if MOAT tests spliterators too.

Well, in?this?case, my?suggestion isn?t?about providing a?fully optimised?`Spliterator`, but?about setting the?correct characteristics.

Otherwise, its?definition is?exactly the?same as?in?`Set::spliterator()`: https://github.com/openjdk/jdk/blob/ead6757486fb58f35f6e93b691519673bca1a549/src/java.base/share/classes/java/util/Set.java#L439-L442

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23095#discussion_r2067134110

From liach at openjdk.org  Tue Apr 29 18:52:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 18:52:48 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v8]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <9iyrabyEzB6jwJ5In-1ik869rqOsybgV1OPha-k6Qcc=.c7656292-a055-44fe-9676-6d13b47812d8@github.com>

On Tue, 29 Apr 2025 18:40:51 GMT, ExE Boss  wrote:

>> Hmm, I intentionally avoided implementing spliterator because there are too many opportunities to optimize - a fully optimized Spliterator implementaton should split an int mask. Can we do that in another patch? I need to check if MOAT tests spliterators too.
>
> Well, in?this?case, my?suggestion isn?t?about providing a?fully optimised?`Spliterator`, but?about setting the?correct characteristics.
> 
> Otherwise, its?definition is?exactly the?same as?in?`Set::spliterator()`: https://github.com/openjdk/jdk/blob/ead6757486fb58f35f6e93b691519673bca1a549/src/java.base/share/classes/java/util/Set.java#L439-L442

I think this probably gets its own RFE - Note that ImmutableCollections.SetN and Set12 (when there are 2 items) uses this default spliterator with no other flags set, even though it can set NONNULL and IMMUTABLE. Same for enum sets.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23095#discussion_r2067147920

From asemenyuk at openjdk.org  Tue Apr 29 18:57:53 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 29 Apr 2025 18:57:53 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 18:28:47 GMT, Christoph  wrote:

> This is unfortunate. However, then how do I add content to the app image before?

You can add custom app content to the app image, but be sure to copy it to the correct location.
You can have "Contents/Resources/jabrefHost.py", but you can not have "Contents/jabrefHost.py".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2839906946

From alanb at openjdk.org  Tue Apr 29 18:58:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Apr 2025 18:58:47 GMT
Subject: RFR: 8355938: Addressed rare lost unpark bug 8074773 by
 pre-loading LockSupport.class
In-Reply-To: 
References: 
 
Message-ID: <66G5gYtjlYEWaFGC6JSFKaYm63GYjECmrylO14IN9uM=.a8951166-7f11-4687-80d1-4b0348deb247@github.com>

On Tue, 29 Apr 2025 18:32:12 GMT, kabutz  wrote:

> What is the potential downside of adding the static block to make sure the class is loaded?

LockSupport is part of the standard API, we can't force every usage to preload this class. So if we have to change anything then it would be better to do it in one place, maybe System.initPhase3. But I think we first need to page in some of the details from 10 years ago.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24952#issuecomment-2839909510

From liach at openjdk.org  Tue Apr 29 19:03:08 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 19:03:08 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v10]
In-Reply-To: 
References: 
Message-ID: <78kIw0fEwr28hUJiXvzVtzJiU45h92XUYbLOMJVx-qU=.41829434-dc66-4f8d-9eb4-b10948f3a2b2@github.com>

> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
> 
> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
> 
> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
> 
> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.

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 17 additional commits since the last revision:

 - Rewrite impl to follow the new simplified spec
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
 - Try to simplify the model - use the finish of computeValue
   
 - Test updates - remove repetition, test case for no stale installation
 - Fix incorrect promise removal when unnecessary and add regression test
 - Cannot test for recursion eagerly - add test case
 - More spec, eager exception, finish with existing, thanks John
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
 - docs
 - Remove the throwing behavior due to shallow reentrancy
 - ... and 7 more: https://git.openjdk.org/jdk/compare/e95db4f9...221d51e7

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24043/files
  - new: https://git.openjdk.org/jdk/pull/24043/files/5ac82864..221d51e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=08-09

  Stats: 8419 lines in 261 files changed: 5850 ins; 916 del; 1653 mod
  Patch: https://git.openjdk.org/jdk/pull/24043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24043/head:pull/24043

PR: https://git.openjdk.org/jdk/pull/24043

From liach at openjdk.org  Tue Apr 29 19:04:45 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 19:04:45 GMT
Subject: RFR: 8355938: Addressed rare lost unpark bug 8074773 by
 pre-loading LockSupport.class
In-Reply-To: 
References: 
Message-ID: 

On Tue, 29 Apr 2025 17:02:38 GMT, kabutz  wrote:

> In 2015, Google discovered a rare disastrous classloading bug in first call to LockSupport.park() that occurred in the AppClassLoader using the Java 7 ConcurrentHashMap, which used ReentrantLock for the synchronization.
> 
> Since then, the recommended fix for this bug seems to be this code snippet in any class that directly calls LockSupport.park():
> 
> 
> static {
>     // Prevent rare disastrous classloading in first call to LockSupport.park.
>     // See: https://bugs.openjdk.java.net/browse/JDK-8074773
>     Class ensureLoaded = LockSupport.class;
> }
> 
> 
> Since the bug was logged, we have seen new classes in the JDK that call LockSupport.park(), but that do not have this code snippet. For example:
> 
> sun.nio.ch.Poller
> jdk.internal.misc.ThreadFlock
> java.util.concurrent.ThreadPerTaskExecutor
> 
> It should probably also be in:
> 
> java.util.concurrent.Exchanger
> 
> Considering how hard this bug is to detect and solve, it would probably be safer to add the code snippet into these newer classes.

The bug description seems like it is a fault in the JVM implementation - if that is the case, a core library bypass is unreliable, as such faults might happen to other classes and cause other consequences; and we might need to fix it from the VM runtime or compiler side, as the original report implies.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24952#issuecomment-2839922275

From iklam at openjdk.org  Tue Apr 29 19:06:08 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 29 Apr 2025 19:06:08 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v6]
In-Reply-To: 
References: 
Message-ID: <7-k-mRPbhetakIoxpfhMvyE1_6O6AAYwDQ-WN-VIXO8=.cf1d562e-9223-4592-ac53-d0a1a3b88b8f@github.com>

> This PR contains 2 parts
> 
> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.
> 
> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):
> 
> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 
> 
> `ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:
> 
> - If an entry has not yet been collected, we make sure it will never be collected.
> - If an entry has been collected, we remove it from the table
> 
> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.
> 
> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.
> 
> In the future, we may relax the implementation to allow for other use cases.

Ioi Lam 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 'master' into 8354897-soft-weak-references-in-aot-cache
 - @fisk offline comments -- tighten up and simplify eligibility check; @DanHeidinga comment -- renamed to MethodType::assemblySetup()
 - @DanHeidinga comments
 - @fisk comment
 - Fixed windows path issues
 - Refactored code
 - Fixed error when running "make test JTREG=AOT_JDK=true TEST=open/test/hotspot/jtreg/runtime/invokedynamic"
 - Work around hotspot/jtreg/sources/TestNoNULL.java
 - Merge branch 'master' into 8354897-soft-weak-references-in-aot-cache
 - cleaned up test cases
 - ... and 4 more: https://git.openjdk.org/jdk/compare/d215cfda...70216566

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24757/files
  - new: https://git.openjdk.org/jdk/pull/24757/files/a25aab03..70216566

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24757&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24757&range=04-05

  Stats: 12881 lines in 388 files changed: 8910 ins; 2004 del; 1967 mod
  Patch: https://git.openjdk.org/jdk/pull/24757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24757/head:pull/24757

PR: https://git.openjdk.org/jdk/pull/24757

From rriggs at openjdk.org  Tue Apr 29 19:08:48 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Apr 2025 19:08:48 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v10]
In-Reply-To: <1aEF2_HxLIHF1wCtPiukcWJoIl-MV6f-JDWoATi7DzU=.b4433c9e-ec66-4ec3-a595-676e460cec7d@github.com>
References: 
 <1aEF2_HxLIHF1wCtPiukcWJoIl-MV6f-JDWoATi7DzU=.b4433c9e-ec66-4ec3-a595-676e460cec7d@github.com>
Message-ID: 

On Mon, 28 Apr 2025 22:07:00 GMT, Chen Liang  wrote:

>> Some AccessFlag parsing methods throw IAE because a flag mask is not valid in a location. However, there is no easy way to check what flag mask bits or what flags are valid for a location. We need such APIs to check, specific to each class file format version.
>> 
>> Also in the investigation, it's noted that `ACC_SYNTHETIC` is incorrectly represented - it is available since release 5.0 instead of release 7. This bug is fixed together for implementation simplicity.
>> 
>> The new methods are all in `AccessFlag.Location`:
>> - `Set flags()`
>> - `int flagsMask()`
>> - `Set flags(ClassFileFormatVersion)`
>> - `int flagsMask(ClassFileFormatVersion)`
>> 
>> Also there is some simplification to `AccessFlag` itself to remove the anonymous classes, which should be more startup-friendly.
>> 
>> Testing: Tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update specs for other existing APIs

lgtm

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 38:

> 36: import java.lang.classfile.attribute.ModuleRequireInfo;
> 37: import java.lang.module.ModuleDescriptor;
> 38: import java.util.*;

Wildcard imports are discouraged.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23095#pullrequestreview-2804659539
PR Review Comment: https://git.openjdk.org/jdk/pull/23095#discussion_r2067147595

From duke at openjdk.org  Tue Apr 29 19:13:50 2025
From: duke at openjdk.org (Johannes Graham)
Date: Tue, 29 Apr 2025 19:13:50 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v46]
In-Reply-To: <3O57UNZ3SXn29fLVtLJ2hm43d798Vt40EIjcvqbcMus=.e8a5dc7a-bb21-44ec-ad66-c11e0a23456f@github.com>
References: 
 <3O57UNZ3SXn29fLVtLJ2hm43d798Vt40EIjcvqbcMus=.e8a5dc7a-bb21-44ec-ad66-c11e0a23456f@github.com>
Message-ID: 

On Tue, 29 Apr 2025 15:10:10 GMT, fabioromano1  wrote:

>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>
> fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adjust the type of operand
>  - Use a more loose formula to do range check
>    
>    Use a more loose formula to do range check, in order not to exclude a priori values that may be inside the supported range

A thought for a future PR  - computing long powers could be useful as a public method as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment-2839942516

From liach at openjdk.org  Tue Apr 29 19:17:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 19:17:02 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v11]
In-Reply-To: 
References: 
Message-ID: 

> Some AccessFlag parsing methods throw IAE because a flag mask is not valid in a location. However, there is no easy way to check what flag mask bits or what flags are valid for a location. We need such APIs to check, specific to each class file format version.
> 
> Also in the investigation, it's noted that `ACC_SYNTHETIC` is incorrectly represented - it is available since release 5.0 instead of release 7. This bug is fixed together for implementation simplicity.
> 
> The new methods are all in `AccessFlag.Location`:
> - `Set flags()`
> - `int flagsMask()`
> - `Set flags(ClassFileFormatVersion)`
> - `int flagsMask(ClassFileFormatVersion)`
> 
> Also there is some simplification to `AccessFlag` itself to remove the anonymous classes, which should be more startup-friendly.
> 
> Testing: Tier 1-3

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Explicit imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23095/files
  - new: https://git.openjdk.org/jdk/pull/23095/files/b651e8d8..1a22005e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23095&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23095&range=09-10

  Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23095.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23095/head:pull/23095

PR: https://git.openjdk.org/jdk/pull/23095

From liach at openjdk.org  Tue Apr 29 19:17:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 19:17:03 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v10]
In-Reply-To: 
References: 
 <1aEF2_HxLIHF1wCtPiukcWJoIl-MV6f-JDWoATi7DzU=.b4433c9e-ec66-4ec3-a595-676e460cec7d@github.com>
 
Message-ID: 

On Tue, 29 Apr 2025 18:49:58 GMT, Roger Riggs  wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update specs for other existing APIs
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 38:
> 
>> 36: import java.lang.classfile.attribute.ModuleRequireInfo;
>> 37: import java.lang.module.ModuleDescriptor;
>> 38: import java.util.*;
> 
> Wildcard imports are discouraged.

I think that was from my ide setting last time when I turned on 5+ wildcard import for java.lang.classfile - I will reset to 99.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23095#discussion_r2067174709

From liach at openjdk.org  Tue Apr 29 19:17:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 19:17:03 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v10]
In-Reply-To: 
References: 
 <1aEF2_HxLIHF1wCtPiukcWJoIl-MV6f-JDWoATi7DzU=.b4433c9e-ec66-4ec3-a595-676e460cec7d@github.com>
 
 
Message-ID: 

On Tue, 29 Apr 2025 19:10:17 GMT, Chen Liang  wrote:

>> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 38:
>> 
>>> 36: import java.lang.classfile.attribute.ModuleRequireInfo;
>>> 37: import java.lang.module.ModuleDescriptor;
>>> 38: import java.util.*;
>> 
>> Wildcard imports are discouraged.
>
> I think that was from my ide setting last time when I turned on 5+ wildcard import for java.lang.classfile - I will reset to 99.

Fixed; please re-review again.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23095#discussion_r2067177403

From asemenyuk at openjdk.org  Tue Apr 29 19:18:03 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 29 Apr 2025 19:18:03 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev  wrote:

> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
> - This change is for macOS only.
> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.

The workaround at [workflows/deployment.yml](https://github.com/JabRef/jabref/blob/97aaab58e3ab543a0f50097ee59e52504d99c786/.github/workflows/deployment.yml#L167-L178) doesn't look right, I'm surprised "codesign" works in the script. Maybe it runs on older macos with a permissive codesign version?

If you want to build app image and create pkg and dmg packages from it in separate steps, you can leverage jpackage's `--app-image` option for this.

1. Build unsigned app image:

jpackage --type app-image ... --dest build/distribution


2. Copy additional content to the app image:

cp buildres/mac/jabrefHost.py build/distribution/JabRef.app/Contents/Resources
cp -R buildres/mac/native-messaging-host build/distribution/JabRef.app/Contents/Resources


3. Create a signed PKG package:

jpackage --type pkg --mac-sign --app-image build/distribution/JabRef.app ...


4. Create a signed DMG package:

jpackage --type dmg --mac-sign --app-image build/distribution/JabRef.app ...


No explicit codesign, hdiutil, and productbuild invocations.
You can have "the dmg background images and install instructions etc".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2839954808

From naoto at openjdk.org  Tue Apr 29 19:36:47 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 29 Apr 2025 19:36:47 GMT
Subject: RFR: 8342886: Update MET timezone in TimeZoneNames files [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 18:11:05 GMT, Gautham Krishnan  wrote:

>> MET timezone entry in TimeZoneNames.java and TimeZoneNames_*.java needs to be updated as MET is alias to Europe/Brussels as per 2024b tzdata changes.
>> 
>> Also Bug4848242.java needs to be removed as the test expects all euro locale time zones should have the same short names.
>
> Gautham Krishnan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/sun/util/resources/TimeZone/Bug4848242.java
>   
>   Co-authored-by: Naoto Sato 

LGTM. Confirmed T1-T3 tests succeeded in our CI system

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24871#pullrequestreview-2804771645

From liach at openjdk.org  Tue Apr 29 19:48:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 19:48:01 GMT
Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to
 class file version [v5]
In-Reply-To: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
Message-ID: 

> Take the class file version to reject flags not yet defined, redefined, or obsoleted. The non-cffv version can return the preview flags when the current runtime is in preview.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
 - Wording updates
 - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
 - Missing since
 - Fix javap causing strictfp tests to fail
 - Further furnish docs
 - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
 - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-cffv-parse
 - Redundant method
 - ... and 1 more: https://git.openjdk.org/jdk/compare/1a22005e...41989440

-------------

Changes: https://git.openjdk.org/jdk/pull/24760/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24760&range=04
  Stats: 233 lines in 14 files changed: 111 ins; 52 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/24760.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24760/head:pull/24760

PR: https://git.openjdk.org/jdk/pull/24760

From pminborg at openjdk.org  Tue Apr 29 19:51:46 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 29 Apr 2025 19:51:46 GMT
Subject: RFR: 8351000: StringBuilder getChar and putChar robustness
In-Reply-To: 
References: 
Message-ID: 

On Tue, 29 Apr 2025 14:10:30 GMT, Roger Riggs  wrote:

> Improve StringBuilder getChar and putChar robustness with racy updates to StringBuilder. 
> Test racing threads with append, insert, and reading characters.

LGTM. Thanks for these improvements.

-------------

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24951#pullrequestreview-2804830116

From rriggs at openjdk.org  Tue Apr 29 19:53:46 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Apr 2025 19:53:46 GMT
Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to
 class file version [v5]
In-Reply-To: 
References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
 
Message-ID: 

On Tue, 29 Apr 2025 19:48:01 GMT, Chen Liang  wrote:

>> Take the class file version to reject flags not yet defined, redefined, or obsoleted. The non-cffv version can return the preview flags when the current runtime is in preview.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - Wording updates
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - Missing since
>  - Fix javap causing strictfp tests to fail
>  - Further furnish docs
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-cffv-parse
>  - Redundant method
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/1a22005e...41989440

It would cleaner separation of API vs javap to have separate PRs for each.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24760#issuecomment-2840075888

From pminborg at openjdk.org  Tue Apr 29 19:57:45 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 29 Apr 2025 19:57:45 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
In-Reply-To: 
References: 
Message-ID: <9zjmdprKixhClHn9Mckp_GQlS3WA_e8jge6xKNBwlls=.0c60a87e-b946-4451-af1b-276a6e476652@github.com>

On Wed, 23 Apr 2025 14:05:58 GMT, Per Minborg  wrote:

> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
> 
> Re-allocated segments are not zeroed between allocations.

> We can not just re-use the original test due to: https://bugs.openjdk.org/browse/JDK-8350455
> 
> See my comment here: [#23142 (comment)](https://github.com/openjdk/jdk/pull/23142#issuecomment-2673194510)

I ran the test 250 times on my Mac machine (macOS 15.4.1)with no problems but, maybe we should problem list or exclude macOS testing?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2840083043

From rriggs at openjdk.org  Tue Apr 29 20:03:49 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Apr 2025 20:03:49 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 19:17:02 GMT, Chen Liang  wrote:

>> Some AccessFlag parsing methods throw IAE because a flag mask is not valid in a location. However, there is no easy way to check what flag mask bits or what flags are valid for a location. We need such APIs to check, specific to each class file format version.
>> 
>> Also in the investigation, it's noted that `ACC_SYNTHETIC` is incorrectly represented - it is available since release 5.0 instead of release 7. This bug is fixed together for implementation simplicity.
>> 
>> The new methods are all in `AccessFlag.Location`:
>> - `Set flags()`
>> - `int flagsMask()`
>> - `Set flags(ClassFileFormatVersion)`
>> - `int flagsMask(ClassFileFormatVersion)`
>> 
>> Also there is some simplification to `AccessFlag` itself to remove the anonymous classes, which should be more startup-friendly.
>> 
>> Testing: Tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicit imports

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23095#pullrequestreview-2804883182

From liach at openjdk.org  Tue Apr 29 20:03:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 20:03:49 GMT
Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to
 class file version [v5]
In-Reply-To: 
References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
 
Message-ID: 

On Tue, 29 Apr 2025 19:48:01 GMT, Chen Liang  wrote:

>> Take the class file version to reject flags not yet defined, redefined, or obsoleted. The non-cffv version can return the preview flags when the current runtime is in preview.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - Wording updates
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - Missing since
>  - Fix javap causing strictfp tests to fail
>  - Further furnish docs
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-cffv-parse
>  - Redundant method
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/1a22005e...41989440

Unfortunately the cffv-aware maskToAccessFlags introduction and old maskToAccessFlags migration to reject STRICTFP are bundled together - this means javap will need an ad-hoc facility to parse instead of using these APIs. Is that the way to go?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24760#issuecomment-2840096776

From rriggs at openjdk.org  Tue Apr 29 20:03:50 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Apr 2025 20:03:50 GMT
Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to
 class file version [v4]
In-Reply-To: 
References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
 
Message-ID: 

On Tue, 29 Apr 2025 16:12:01 GMT, Chen Liang  wrote:

>> Take the class file version to reject flags not yet defined, redefined, or obsoleted. The non-cffv version can return the preview flags when the current runtime is in preview.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Wording updates
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - Missing since
>  - Fix javap causing strictfp tests to fail
>  - Further furnish docs
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-cffv-parse
>  - Redundant method
>  - 8297271: AccessFlag.maskToAccessFlags should be specific to class file version

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 401:

> 399:     public static Set maskToAccessFlags(int mask, Location location, ClassFileFormatVersion cffv) {
> 400:         var definition = findDefinition(location);
> 401:         int unmatchedMask = mask & (~location.flagsMask(cffv)); // implicit null check

Implicit null check is actually in `findDefinition`.
There's little harm is looking up the definition before checking for unmatched mask bits but it could be delayed and inlined as the argument to `new AccessFlagSet`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24760#discussion_r2067235737

From liach at openjdk.org  Tue Apr 29 20:03:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 20:03:51 GMT
Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to
 class file version [v4]
In-Reply-To: 
References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
 
 
Message-ID: 

On Tue, 29 Apr 2025 19:41:23 GMT, Roger Riggs  wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - Wording updates
>>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>>  - Missing since
>>  - Fix javap causing strictfp tests to fail
>>  - Further furnish docs
>>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-cffv-parse
>>  - Redundant method
>>  - 8297271: AccessFlag.maskToAccessFlags should be specific to class file version
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 401:
> 
>> 399:     public static Set maskToAccessFlags(int mask, Location location, ClassFileFormatVersion cffv) {
>> 400:         var definition = findDefinition(location);
>> 401:         int unmatchedMask = mask & (~location.flagsMask(cffv)); // implicit null check
> 
> Implicit null check is actually in `findDefinition`.
> There's little harm is looking up the definition before checking for unmatched mask bits but it could be delayed and inlined as the argument to `new AccessFlagSet`.

Oops, this was the implicit null check for cffv. Should I make all of the checks explicit?

Also, I split out `findDefinition` as in value objects, it will become `findDefinition(location, cffv)`, when the valhalla cffv is passed, findDefinition can return differently for Location.CLASS.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24760#discussion_r2067292304

From rriggs at openjdk.org  Tue Apr 29 20:08:46 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Apr 2025 20:08:46 GMT
Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to
 class file version [v5]
In-Reply-To: 
References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
 
 
Message-ID: 

On Tue, 29 Apr 2025 19:59:46 GMT, Chen Liang  wrote:

> Unfortunately the cffv-aware maskToAccessFlags introduction and old maskToAccessFlags migration to reject STRICTFP are bundled together - this means javap will need an ad-hoc facility to parse instead of using these APIs. Is that the way to go?

If there's hard dependency, as in depending on new APIs; ok as is.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24760#issuecomment-2840112813

From rriggs at openjdk.org  Tue Apr 29 20:14:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Apr 2025 20:14:53 GMT
Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to
 class file version [v4]
In-Reply-To: 
References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
 
 
 
Message-ID: 

On Tue, 29 Apr 2025 20:01:23 GMT, Chen Liang  wrote:

>> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 401:
>> 
>>> 399:     public static Set maskToAccessFlags(int mask, Location location, ClassFileFormatVersion cffv) {
>>> 400:         var definition = findDefinition(location);
>>> 401:         int unmatchedMask = mask & (~location.flagsMask(cffv)); // implicit null check
>> 
>> Implicit null check is actually in `findDefinition`.
>> There's little harm is looking up the definition before checking for unmatched mask bits but it could be delayed and inlined as the argument to `new AccessFlagSet`.
>
> Oops, this was the implicit null check for cffv. Should I make all of the checks explicit?
> 
> Also, I split out `findDefinition` as in value objects, it will become `findDefinition(location, cffv)`, when the valhalla cffv is passed, findDefinition can return differently for Location.CLASS.

Explicit null checks are better if they provide if they name the caller supplied argument that was null.
Checking for caller errors usually precedes the methods semantics.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24760#discussion_r2067327110

From eosterlund at openjdk.org  Tue Apr 29 20:17:52 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 29 Apr 2025 20:17:52 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v6]
In-Reply-To: <7-k-mRPbhetakIoxpfhMvyE1_6O6AAYwDQ-WN-VIXO8=.cf1d562e-9223-4592-ac53-d0a1a3b88b8f@github.com>
References: 
 <7-k-mRPbhetakIoxpfhMvyE1_6O6AAYwDQ-WN-VIXO8=.cf1d562e-9223-4592-ac53-d0a1a3b88b8f@github.com>
Message-ID: <0bbKpQSv7zxOdKFLiZZGgQloA38yKde9ExYJ9pR7WvU=.98fc0347-f3b6-4546-b6a2-f97bfadd82ad@github.com>

On Tue, 29 Apr 2025 19:06:08 GMT, Ioi Lam  wrote:

>> This PR contains 2 parts
>> 
>> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
>> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.
>> 
>> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):
>> 
>> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
>> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 
>> 
>> `ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:
>> 
>> - If an entry has not yet been collected, we make sure it will never be collected.
>> - If an entry has been collected, we remove it from the table
>> 
>> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.
>> 
>> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.
>> 
>> In the future, we may relax the implementation to allow for other use cases.
>
> Ioi Lam 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 'master' into 8354897-soft-weak-references-in-aot-cache
>  - @fisk offline comments -- tighten up and simplify eligibility check; @DanHeidinga comment -- renamed to MethodType::assemblySetup()
>  - @DanHeidinga comments
>  - @fisk comment
>  - Fixed windows path issues
>  - Refactored code
>  - Fixed error when running "make test JTREG=AOT_JDK=true TEST=open/test/hotspot/jtreg/runtime/invokedynamic"
>  - Work around hotspot/jtreg/sources/TestNoNULL.java
>  - Merge branch 'master' into 8354897-soft-weak-references-in-aot-cache
>  - cleaned up test cases
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/09137395...70216566

Other than reading the referent with the wrong accessor in the assert, I think this looks very good. Thanks for sorting this out in a clean and robust way.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24757#pullrequestreview-2804941687

From bchristi at openjdk.org  Tue Apr 29 20:17:58 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 29 Apr 2025 20:17:58 GMT
Subject: Integrated: 8355632: WhiteBox.waitForReferenceProcessing() fails
 assert for return type
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Apr 2025 23:37:13 GMT, Brent Christian  wrote:

> The newly-added `WhiteBox.waitForReferenceProcessing()` (see [8305186](https://bugs.openjdk.org/browse/JDK-8305186)) always fails with assertions enabled.
> I've updated the assertion, and also added the test I used locally to test the new method (just not with assertions enabled, apparently.)

This pull request has now been integrated.

Changeset: bf52eb03
Author:    Brent Christian 
URL:       https://git.openjdk.org/jdk/commit/bf52eb035865353fdf5c6c242f9676a51dcc9e22
Stats:     31 lines in 2 files changed: 30 ins; 0 del; 1 mod

8355632: WhiteBox.waitForReferenceProcessing() fails assert for return type

Reviewed-by: kbarrett

-------------

PR: https://git.openjdk.org/jdk/pull/24892

From duke at openjdk.org  Tue Apr 29 20:21:29 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Apr 2025 20:21:29 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v47]
In-Reply-To: 
References: 
Message-ID: 

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Use a more accurate formula to detect certain overflows

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/925806bd..ad49b56e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=46
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=45-46

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From schernyshev at openjdk.org  Tue Apr 29 20:32:52 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 29 Apr 2025 20:32:52 GMT
Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 14:45:25 GMT, PAWAN CHAWDHARY  wrote:

>> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update reference of DockerVersion

test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 74:

> 72:             return;
> 73:         }
> 74:         if (IS_DOCKER && TestDockerMemoryMetricsSubgroup.DockerVersion.VERSION_20_10_0.compareTo(getDockerVersion()) > 0) {

Should this change also cover Podman, in which the minimum version that supports `--cgroupns` is 3.0 ?

test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 149:

> 147:     }
> 148: 
> 149:     private static class DockerVersion implements Comparable {

The same code is added to multiple tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2067344723
PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2067371874

From duke at openjdk.org  Tue Apr 29 20:33:29 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Apr 2025 20:33:29 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v48]
In-Reply-To: 
References: 
Message-ID: 

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Simplified the formula for detecting overflows

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/ad49b56e..68959267

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=47
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=46-47

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From jvernee at openjdk.org  Tue Apr 29 20:34:46 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 29 Apr 2025 20:34:46 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
In-Reply-To: <9zjmdprKixhClHn9Mckp_GQlS3WA_e8jge6xKNBwlls=.0c60a87e-b946-4451-af1b-276a6e476652@github.com>
References: 
 <9zjmdprKixhClHn9Mckp_GQlS3WA_e8jge6xKNBwlls=.0c60a87e-b946-4451-af1b-276a6e476652@github.com>
Message-ID: 

On Tue, 29 Apr 2025 19:54:07 GMT, Per Minborg  wrote:

> maybe we should problem list or exclude macOS testing?

Yes, I think we should. The issue is quite intermittent, and last time it only started showing up in CI as well. I think we should move the `stress()` test to a separate file./jtreg test, and then problem list that test on Mac, with a link to JDK-8350455

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2840172403

From liach at openjdk.org  Tue Apr 29 20:46:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 20:46:50 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v6]
In-Reply-To: <7-k-mRPbhetakIoxpfhMvyE1_6O6AAYwDQ-WN-VIXO8=.cf1d562e-9223-4592-ac53-d0a1a3b88b8f@github.com>
References: 
 <7-k-mRPbhetakIoxpfhMvyE1_6O6AAYwDQ-WN-VIXO8=.cf1d562e-9223-4592-ac53-d0a1a3b88b8f@github.com>
Message-ID: 

On Tue, 29 Apr 2025 19:06:08 GMT, Ioi Lam  wrote:

>> This PR contains 2 parts
>> 
>> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
>> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.
>> 
>> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):
>> 
>> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
>> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 
>> 
>> `ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:
>> 
>> - If an entry has not yet been collected, we make sure it will never be collected.
>> - If an entry has been collected, we remove it from the table
>> 
>> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.
>> 
>> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.
>> 
>> In the future, we may relax the implementation to allow for other use cases.
>
> Ioi Lam 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 'master' into 8354897-soft-weak-references-in-aot-cache
>  - @fisk offline comments -- tighten up and simplify eligibility check; @DanHeidinga comment -- renamed to MethodType::assemblySetup()
>  - @DanHeidinga comments
>  - @fisk comment
>  - Fixed windows path issues
>  - Refactored code
>  - Fixed error when running "make test JTREG=AOT_JDK=true TEST=open/test/hotspot/jtreg/runtime/invokedynamic"
>  - Work around hotspot/jtreg/sources/TestNoNULL.java
>  - Merge branch 'master' into 8354897-soft-weak-references-in-aot-cache
>  - cleaned up test cases
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/1148b00f...70216566

The core library changes look good.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24757#pullrequestreview-2805045349

From liach at openjdk.org  Tue Apr 29 20:47:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 20:47:57 GMT
Subject: RFR: 8355956: Prepare javap for class file format aware access flag
 parsing
Message-ID: 

A prerequisite to #24760; this was part of it, but was split out to simplify the review of the addition of `maskToAccessFlags(int, Location, CFFV)` by minimizing the changes in javap. That patch will only need to update `BasicWriter` as a result.

Testing: langtools/tools/javap, tier 1+2 underway

-------------

Commit messages:
 - 8355956: Prepare javap for class file format aware access flag parsing

Changes: https://git.openjdk.org/jdk/pull/24955/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24955&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355956
  Stats: 110 lines in 5 files changed: 50 ins; 22 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/24955.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24955/head:pull/24955

PR: https://git.openjdk.org/jdk/pull/24955

From jiangli at openjdk.org  Tue Apr 29 21:39:50 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 29 Apr 2025 21:39:50 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: 
References: 
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
 
Message-ID: <7dQZdXM5rw2AAwubnEkRaJhiGPzNDzFDmSRVrEnEa_g=.5011ef91-af54-404d-84a5-e252778fe935@github.com>

On Tue, 29 Apr 2025 06:43:59 GMT, Magnus Ihse Bursie  wrote:

>> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
>>  - Address henryjen@ comment:
>>    - Remove '#include '.
>
> This was news to me. I'm thinking about what this means in terms of the static build, where all native JDK libraries are "loaded" as soon as the application starts executing. Do we have native libraries in the JDK that are not loaded by the boot loader? If so, have we introduced some corner case effects by marking them with the static JNI symbol? ?

@magicus For existing JDK JNI native libraries, I think adding `DEF_STATIC_JNI_OnLoad` (if missing) does not affect the classloader usage associated with the library. The static support for built-in JNI native library affects the native "load" operation (e.g. on Linux `dlopen`) only ([Java_jdk_internal_loader_NativeLibraries_load](https://github.com/openjdk/jdk/blob/c2485d5f7dd00eaed34a5d309276114eb4c78cb0/src/java.base/share/native/libjava/NativeLibraries.c#L119). Double checking [Java_jdk_internal_loader_NativeLibraries_unload](https://github.com/openjdk/jdk/blob/c2485d5f7dd00eaed34a5d309276114eb4c78cb0/src/java.base/share/native/libjava/NativeLibraries.c#L180), the existing code also makes sure `JVM_UnloadLibrary` is not called to "unload" (e.g. on Linux `dlclose`) built-in JNI native library.

The reason why boot loader question/consideration brought up in this thread was because `libsyslookup` was not associated with the boot loader but now does with the change in src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2840305879

From jvernee at openjdk.org  Tue Apr 29 21:41:49 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 29 Apr 2025 21:41:49 GMT
Subject: RFR: 8355442: Reference field lambda forms with type casts are not
 generated [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 26 Apr 2025 23:47:01 GMT, Chen Liang  wrote:

>> Currently, we are not generating all possible field lambda forms.
>> 
>> Field lambda forms have these dimensions:
>> - get/set
>> - instance/static/static+class init barrier
>> - plain/volatile
>> - 8 primitive types, no-cast object, object with cast
>> 
>> Bringing to a total of 2 ? 3 ? 2 ? 10 = 120 lambda forms.
>> 
>> Previously, the ones with init barrier or object with cast types were not generated due to spamming the Kind enum. In retrospect, I believe skipping the object with cast form is a poor choice - tons of Java fields are using non-interface types. Also seems the volatile accessors were omitted in InvokerBytecodeGenerator, which made their pregen useless.
>> 
>> I have utilized erased method types to distinguish forms - get/set, 5 basic types, and instance/static can be distinguished by the types, so the Kind enums now only represent init, volatile, and non-basic types (byte, char, short, boolean, casts), bringing the total constants to 24 down from 40 previously.
>> 
>> In the long run, we should investigate update `Kind` to allow flexible representations - an enum is too restrictive especially with the erased types.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use var

src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java line 626:

> 624:             FT_UNCHECKED_REF   = Wrapper.OBJECT.ordinal(),
> 625:             FT_CHECKED_REF     = Wrapper.VOID.ordinal(),
> 626:             FT_LIMIT           = Wrapper.COUNT;

I don't see why these changes are needed?

src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 440:

> 438:                     throw new InternalError(b + " non-volatile " + ftype);
> 439:                 forms.add(form);
> 440:                 names.add(form.kind.defaultLambdaName);

I suppose the fact that static/non-static variants have the same name is okay since they will have a different number of parameters?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24887#discussion_r2067451587
PR Review Comment: https://git.openjdk.org/jdk/pull/24887#discussion_r2067447230

From liach at openjdk.org  Tue Apr 29 21:41:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 21:41:49 GMT
Subject: RFR: 8355442: Reference field lambda forms with type casts are not
 generated [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 29 Apr 2025 21:24:11 GMT, Jorn Vernee  wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use var
>
> src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java line 626:
> 
>> 624:             FT_UNCHECKED_REF   = Wrapper.OBJECT.ordinal(),
>> 625:             FT_CHECKED_REF     = Wrapper.VOID.ordinal(),
>> 626:             FT_LIMIT           = Wrapper.COUNT;
> 
> I don't see why these changes are needed?

These avoid wasting space in the field lambda form array.

> src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 440:
> 
>> 438:                     throw new InternalError(b + " non-volatile " + ftype);
>> 439:                 forms.add(form);
>> 440:                 names.add(form.kind.defaultLambdaName);
> 
> I suppose the fact that static/non-static variants have the same name is okay since they will have a different number of parameters?

Yep, I left the comment at https://github.com/openjdk/jdk/pull/24887/files#diff-62978b9d88b0791f31c654103e6b97eea8bf711fa37ac4bf614847b26f44e0c1R761

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24887#discussion_r2067468413
PR Review Comment: https://git.openjdk.org/jdk/pull/24887#discussion_r2067469292

From bchristi at openjdk.org  Tue Apr 29 21:56:10 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 29 Apr 2025 21:56:10 GMT
Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed
 with "RuntimeException: MyObject is not found in test output" [v6]
In-Reply-To: 
References: 
Message-ID: 

> I propose some cleanups to `FinalizerHistogramTest.java` to hopefully clear up the intermittent failures:
> 
> * run with `othervm`: this test blocks the (global) finalizer thread, and also requires the (global) finalizer thread to enter the test's `finalize()` method
> * The test uses `volatile` ints, but sets them based on their current value, which is not reliable; convert to `AtomicInteger`
> * use `PhantomReference`s to ensure that at least two `MyObject`s have become unreachable. If one is stuck in `finalize()`, at least one is still waiting to be finalized and should show up in the histogram.

Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'master' into 8298783
 - Merge branch 'master' into 8298783
 - convert to WeakRefs, use a RefQ, print ForceGC results
 - 'return' not needed in lambda
 - rename counter variables to use 'Count'
 - test reliability improvements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24143/files
  - new: https://git.openjdk.org/jdk/pull/24143/files/cfbb4230..3a7d12bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24143&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24143&range=04-05

  Stats: 8982 lines in 270 files changed: 6532 ins; 784 del; 1666 mod
  Patch: https://git.openjdk.org/jdk/pull/24143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24143/head:pull/24143

PR: https://git.openjdk.org/jdk/pull/24143

From asemenyuk at openjdk.org  Tue Apr 29 21:56:48 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 29 Apr 2025 21:56:48 GMT
Subject: RFR: 8355651: Issues with post-image hook [v2]
In-Reply-To: <0BBg6RbUThxeP5kCFXwZZWPKQM26LvwCR3NtGTUkO-I=.ab23eae5-e388-4478-aeaa-ff0ec011d814@github.com>
References: <5RuvuTl0kW-MbAAb0sJb1zkBnWUAnNTHKp2r8wQwiz8=.34a6dd59-aa49-4f51-b128-222e4116e922@github.com>
 <0BBg6RbUThxeP5kCFXwZZWPKQM26LvwCR3NtGTUkO-I=.ab23eae5-e388-4478-aeaa-ff0ec011d814@github.com>
Message-ID: 

On Tue, 29 Apr 2025 13:40:59 GMT, Alexey Semenyuk  wrote:

>> - Add missing "post-image" infrastructure on Linux.
>>  - Fix "post-image" infrastructure on macOS and Windows.
>>  - Add relevant tests.
>>  - Update TKit to support new tests.
>
> Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 10 new commits since the last revision:
> 
>  - Fix modifiers order
>  - Update src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java
>    
>    Co-authored-by: Hendrik Schick <30866028+ky0n at users.noreply.github.com>
>  - Better test coverage
>  - Change signature of TKit.assertEquals(String, String, String) to TKit.assertEquals(Object, Object, String)
>  - Add Comm.uniqueEmpty()
>  - - Add TKit.assertDirectoryContentRecursive()
>    - Fix log messages of TKit.assertDirectoryExists()
>  - Reorder actions in PKG packaging to ensure user post-image script is invoked before any PKG is created.
>  - Fix formatting
>  - - Add missing "post-image" script execution to Linux bundlers
>    - Add tests to verify the context of "post-image" script on all platforms
>    - Set current directory for "post-image" script on Windows and macOS inside of the app image directory
>  - 8355651: Premature execution of post-image hook

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24899#issuecomment-2840331641

From iklam at openjdk.org  Tue Apr 29 22:22:05 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 29 Apr 2025 22:22:05 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v7]
In-Reply-To: 
References: 
Message-ID: 

> This PR contains 2 parts
> 
> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.
> 
> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):
> 
> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 
> 
> `ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:
> 
> - If an entry has not yet been collected, we make sure it will never be collected.
> - If an entry has been collected, we remove it from the table
> 
> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.
> 
> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.
> 
> In the future, we may relax the implementation to allow for other use cases.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @fisk comment -- use proper HeapAccess to load referent; Also refactor AOTReferenceObjSupport::is_enabled()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24757/files
  - new: https://git.openjdk.org/jdk/pull/24757/files/70216566..01f0ea0e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24757&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24757&range=05-06

  Stats: 25 lines in 3 files changed: 22 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24757/head:pull/24757

PR: https://git.openjdk.org/jdk/pull/24757

From jvernee at openjdk.org  Tue Apr 29 22:26:45 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 29 Apr 2025 22:26:45 GMT
Subject: RFR: 8355442: Reference field lambda forms with type casts are not
 generated [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 26 Apr 2025 23:47:01 GMT, Chen Liang  wrote:

>> Currently, we are not generating all possible field lambda forms.
>> 
>> Field lambda forms have these dimensions:
>> - get/set
>> - instance/static/static+class init barrier
>> - plain/volatile
>> - 8 primitive types, no-cast object, object with cast
>> 
>> Bringing to a total of 2 ? 3 ? 2 ? 10 = 120 lambda forms.
>> 
>> Previously, the ones with init barrier or object with cast types were not generated due to spamming the Kind enum. In retrospect, I believe skipping the object with cast form is a poor choice - tons of Java fields are using non-interface types. Also seems the volatile accessors were omitted in InvokerBytecodeGenerator, which made their pregen useless.
>> 
>> I have utilized erased method types to distinguish forms - get/set, 5 basic types, and instance/static can be distinguished by the types, so the Kind enums now only represent init, volatile, and non-basic types (byte, char, short, boolean, casts), bringing the total constants to 24 down from 40 previously.
>> 
>> In the long run, we should investigate update `Kind` to allow flexible representations - an enum is too restrictive especially with the erased types.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use var

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24887#pullrequestreview-2805208547

From vlivanov at openjdk.org  Tue Apr 29 22:27:51 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 29 Apr 2025 22:27:51 GMT
Subject: Integrated: 8355689: Wrong native entry name for FloatMaxVector vector
 math stubs with -XX:MaxVectorSize=8
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Apr 2025 19:41:28 GMT, Vladimir Ivanov  wrote:

> Both SVML and SLEEF libraries reuse 128-bit versions for vector of 2 floats. Usually, only `Float64Vector` shape satisfies that condiditon, but with`-XX:MaxVectorSize=8` `FloatMaxVector` becomes 2 element vector as well. 
> 
> Adjust the relevant logic to match vector of 2 floats shape structurally. 
> 
> Testing: failing regression test, hs-tier1 - hs-tier4

This pull request has now been integrated.

Changeset: 6850757f
Author:    Vladimir Ivanov 
URL:       https://git.openjdk.org/jdk/commit/6850757fe6c6c7868fab2314babb7c30bce2662e
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8355689: Wrong native entry name for FloatMaxVector vector math stubs with -XX:MaxVectorSize=8

Reviewed-by: psandoz, haosun, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/24936

From vlivanov at openjdk.org  Tue Apr 29 22:27:50 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 29 Apr 2025 22:27:50 GMT
Subject: RFR: 8355689: Wrong native entry name for FloatMaxVector vector
 math stubs with -XX:MaxVectorSize=8
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Apr 2025 19:41:28 GMT, Vladimir Ivanov  wrote:

> Both SVML and SLEEF libraries reuse 128-bit versions for vector of 2 floats. Usually, only `Float64Vector` shape satisfies that condiditon, but with`-XX:MaxVectorSize=8` `FloatMaxVector` becomes 2 element vector as well. 
> 
> Adjust the relevant logic to match vector of 2 floats shape structurally. 
> 
> Testing: failing regression test, hs-tier1 - hs-tier4

Thanks for the reviews, Paul, Vladimir, and Hao.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24936#issuecomment-2840373156

From bchristi at openjdk.org  Tue Apr 29 22:46:22 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 29 Apr 2025 22:46:22 GMT
Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed
 with "RuntimeException: MyObject is not found in test output" [v7]
In-Reply-To: 
References: 
Message-ID: 

> I propose some cleanups to `FinalizerHistogramTest.java` to hopefully clear up the intermittent failures:
> 
> * run with `othervm`: this test blocks the (global) finalizer thread, and also requires the (global) finalizer thread to enter the test's `finalize()` method
> * The test uses `volatile` ints, but sets them based on their current value, which is not reliable; convert to `AtomicInteger`
> * use `PhantomReference`s to ensure that at least two `MyObject`s have become unreachable. If one is stuck in `finalize()`, at least one is still waiting to be finalized and should show up in the histogram.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  convert test to use WhiteBox

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24143/files
  - new: https://git.openjdk.org/jdk/pull/24143/files/3a7d12bf..10c8a9e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24143&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24143&range=05-06

  Stats: 61 lines in 1 file changed: 6 ins; 44 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/24143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24143/head:pull/24143

PR: https://git.openjdk.org/jdk/pull/24143

From liach at openjdk.org  Tue Apr 29 23:09:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 23:09:50 GMT
Subject: RFR: 8355442: Reference field lambda forms with type casts are not
 generated [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 26 Apr 2025 23:47:01 GMT, Chen Liang  wrote:

>> Currently, we are not generating all possible field lambda forms.
>> 
>> Field lambda forms have these dimensions:
>> - get/set
>> - instance/static/static+class init barrier
>> - plain/volatile
>> - 8 primitive types, no-cast object, object with cast
>> 
>> Bringing to a total of 2 ? 3 ? 2 ? 10 = 120 lambda forms.
>> 
>> Previously, the ones with init barrier or object with cast types were not generated due to spamming the Kind enum. In retrospect, I believe skipping the object with cast form is a poor choice - tons of Java fields are using non-interface types. Also seems the volatile accessors were omitted in InvokerBytecodeGenerator, which made their pregen useless.
>> 
>> I have utilized erased method types to distinguish forms - get/set, 5 basic types, and instance/static can be distinguished by the types, so the Kind enums now only represent init, volatile, and non-basic types (byte, char, short, boolean, casts), bringing the total constants to 24 down from 40 previously.
>> 
>> In the long run, we should investigate update `Kind` to allow flexible representations - an enum is too restrictive especially with the erased types.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use var

Thank you for your review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24887#issuecomment-2840427737

From liach at openjdk.org  Tue Apr 29 23:09:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Apr 2025 23:09:50 GMT
Subject: Integrated: 8355442: Reference field lambda forms with type casts are
 not generated
In-Reply-To: 
References: 
Message-ID: <2CwB6p_3Lf4T0PGiILlzTCd8808FUnug0ijsHfGfT0Q=.827336e7-b5aa-45dd-8bcb-3bc43848d3b0@github.com>

On Fri, 25 Apr 2025 20:30:15 GMT, Chen Liang  wrote:

> Currently, we are not generating all possible field lambda forms.
> 
> Field lambda forms have these dimensions:
> - get/set
> - instance/static/static+class init barrier
> - plain/volatile
> - 8 primitive types, no-cast object, object with cast
> 
> Bringing to a total of 2 ? 3 ? 2 ? 10 = 120 lambda forms.
> 
> Previously, the ones with init barrier or object with cast types were not generated due to spamming the Kind enum. In retrospect, I believe skipping the object with cast form is a poor choice - tons of Java fields are using non-interface types. Also seems the volatile accessors were omitted in InvokerBytecodeGenerator, which made their pregen useless.
> 
> I have utilized erased method types to distinguish forms - get/set, 5 basic types, and instance/static can be distinguished by the types, so the Kind enums now only represent init, volatile, and non-basic types (byte, char, short, boolean, casts), bringing the total constants to 24 down from 40 previously.
> 
> In the long run, we should investigate update `Kind` to allow flexible representations - an enum is too restrictive especially with the erased types.

This pull request has now been integrated.

Changeset: 16529488
Author:    Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/1652948862c135c67d52622062773bf7922e02d0
Stats:     159 lines in 4 files changed: 29 ins; 37 del; 93 mod

8355442: Reference field lambda forms with type casts are not generated

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/24887

From duke at openjdk.org  Tue Apr 29 23:20:46 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Tue, 29 Apr 2025 23:20:46 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms
In-Reply-To: <1pQ0qy9CEbpJ6Qd6VRuHGrM5aObN7MTOrIgOIliNWvQ=.b0babb5e-bf97-46a0-8800-72d55e0b592b@github.com>
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 <1pQ0qy9CEbpJ6Qd6VRuHGrM5aObN7MTOrIgOIliNWvQ=.b0babb5e-bf97-46a0-8800-72d55e0b592b@github.com>
Message-ID: 

On Sat, 26 Apr 2025 11:01:58 GMT, Andrew Haley  wrote:

> > the built in **cbrt** micro-benchmark
> 
> How should we run that benchmark? Thanks.

`make test TEST="micro:MathBench.cbrt"`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24470#issuecomment-2840442518

From kbarrett at openjdk.org  Tue Apr 29 23:22:46 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 29 Apr 2025 23:22:46 GMT
Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed
 with "RuntimeException: MyObject is not found in test output" [v7]
In-Reply-To: 
References: 
 
Message-ID: <1tGRJ4ejgEBN_prDxdLQajmtGU4whVg5OAH8ziKR3pQ=.9b4a8e19-0fec-43a3-a357-4f63d6f7078c@github.com>

On Tue, 29 Apr 2025 22:46:22 GMT, Brent Christian  wrote:

>> I propose some cleanups to `FinalizerHistogramTest.java` to hopefully clear up the intermittent failures:
>> 
>> * run with `othervm`: this test blocks the (global) finalizer thread, and also requires the (global) finalizer thread to enter the test's `finalize()` method
>> * The test uses `volatile` ints, but sets them based on their current value, which is not reliable; convert to `AtomicInteger`
>> * use `PhantomReference`s to ensure that at least two `MyObject`s have become unreachable. If one is stuck in `finalize()`, at least one is still waiting to be finalized and should show up in the histogram.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   convert test to use WhiteBox

Changes requested by kbarrett (Reviewer).

test/jdk/java/lang/ref/FinalizerHistogramTest.java line 77:

> 75:             wb = WhiteBox.getWhiteBox();
> 76:             wb.fullGC();
> 77:             refProResult = wb.waitForReferenceProcessing();

WhiteBox::waitForReferenceProcessing returns true if some progress has been made, not if all the 
processing is done.  Probably need a loop here, e.g.

while (wb.waitForReferenceProcessing()) {}
// All finalizable objects from prior gcs have made it to the finalizer queue.

test/jdk/java/lang/ref/FinalizerHistogramTest.java line 79:

> 77:             refProResult = wb.waitForReferenceProcessing();
> 78:             System.out.println("waitForReferenceProcessing returned: " + refProResult);
> 79:             while(trappedCount.get() < 1);

This doesn't seem to be doing anything?  trappedCount is initially 0, and only incremented.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24143#pullrequestreview-2805296214
PR Review Comment: https://git.openjdk.org/jdk/pull/24143#discussion_r2067567008
PR Review Comment: https://git.openjdk.org/jdk/pull/24143#discussion_r2067567096

From duke at openjdk.org  Tue Apr 29 23:23:47 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Tue, 29 Apr 2025 23:23:47 GMT
Subject: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms
In-Reply-To: 
References: <1NsI0OGP9RcnbEwlJwDj1dZ3w7zCP4DxJhEmO1quSgo=.3b1e3da9-9aa9-4221-a73a-e2f3ec5f456b@github.com>
 
Message-ID: 

On Sat, 26 Apr 2025 10:04:38 GMT, Andrew Haley  wrote:

> What are the monotonicity and accuracy results for this approximation? Is it correctly rounded or faithfully rounded?

1. It's monotonic.
2. It has a maximum error of 0.5213 ULP.
3. It's not correctly rounded but it is faithfully rounded.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24470#issuecomment-2840446079

From almatvee at openjdk.org  Tue Apr 29 23:41:46 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 29 Apr 2025 23:41:46 GMT
Subject: RFR: 8355651: Issues with post-image hook [v2]
In-Reply-To: <0BBg6RbUThxeP5kCFXwZZWPKQM26LvwCR3NtGTUkO-I=.ab23eae5-e388-4478-aeaa-ff0ec011d814@github.com>
References: <5RuvuTl0kW-MbAAb0sJb1zkBnWUAnNTHKp2r8wQwiz8=.34a6dd59-aa49-4f51-b128-222e4116e922@github.com>
 <0BBg6RbUThxeP5kCFXwZZWPKQM26LvwCR3NtGTUkO-I=.ab23eae5-e388-4478-aeaa-ff0ec011d814@github.com>
Message-ID: <1ZFJZ-SQaCBILW92XRpZikoxZ5_k47JPXj4kKj0s1ts=.46db9d0a-71c1-4896-9303-3229c73f3e71@github.com>

On Tue, 29 Apr 2025 13:40:59 GMT, Alexey Semenyuk  wrote:

>> - Add missing "post-image" infrastructure on Linux.
>>  - Fix "post-image" infrastructure on macOS and Windows.
>>  - Add relevant tests.
>>  - Update TKit to support new tests.
>
> Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 10 new commits since the last revision:
> 
>  - Fix modifiers order
>  - Update src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java
>    
>    Co-authored-by: Hendrik Schick <30866028+ky0n at users.noreply.github.com>
>  - Better test coverage
>  - Change signature of TKit.assertEquals(String, String, String) to TKit.assertEquals(Object, Object, String)
>  - Add Comm.uniqueEmpty()
>  - - Add TKit.assertDirectoryContentRecursive()
>    - Fix log messages of TKit.assertDirectoryExists()
>  - Reorder actions in PKG packaging to ensure user post-image script is invoked before any PKG is created.
>  - Fix formatting
>  - - Add missing "post-image" script execution to Linux bundlers
>    - Add tests to verify the context of "post-image" script on all platforms
>    - Set current directory for "post-image" script on Windows and macOS inside of the app image directory
>  - 8355651: Premature execution of post-image hook

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24899#pullrequestreview-2805330867

From jrose at openjdk.org  Wed Apr 30 00:16:49 2025
From: jrose at openjdk.org (John R Rose)
Date: Wed, 30 Apr 2025 00:16:49 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v10]
In-Reply-To: <78kIw0fEwr28hUJiXvzVtzJiU45h92XUYbLOMJVx-qU=.41829434-dc66-4f8d-9eb4-b10948f3a2b2@github.com>
References: 
 <78kIw0fEwr28hUJiXvzVtzJiU45h92XUYbLOMJVx-qU=.41829434-dc66-4f8d-9eb4-b10948f3a2b2@github.com>
Message-ID: 

On Tue, 29 Apr 2025 19:03:08 GMT, Chen Liang  wrote:

>> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
>> 
>> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
>> 
>> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
>> 
>> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.
>
> 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 17 additional commits since the last revision:
> 
>  - Rewrite impl to follow the new simplified spec
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - Try to simplify the model - use the finish of computeValue
>    
>  - Test updates - remove repetition, test case for no stale installation
>  - Fix incorrect promise removal when unnecessary and add regression test
>  - Cannot test for recursion eagerly - add test case
>  - More spec, eager exception, finish with existing, thanks John
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - docs
>  - Remove the throwing behavior due to shallow reentrancy
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/91761352...221d51e7

Excellent. Much better documented and more clearly correct.

-------------

Marked as reviewed by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24043#pullrequestreview-2805399165

From zgu at openjdk.org  Wed Apr 30 00:31:52 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Wed, 30 Apr 2025 00:31:52 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 22:22:05 GMT, Ioi Lam  wrote:

>> This PR contains 2 parts
>> 
>> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
>> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.
>> 
>> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):
>> 
>> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
>> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 
>> 
>> `ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:
>> 
>> - If an entry has not yet been collected, we make sure it will never be collected.
>> - If an entry has been collected, we remove it from the table
>> 
>> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.
>> 
>> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.
>> 
>> In the future, we may relax the implementation to allow for other use cases.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @fisk comment -- use proper HeapAccess to load referent; Also refactor AOTReferenceObjSupport::is_enabled()

src/hotspot/share/cds/aotReferenceObjSupport.cpp line 122:

> 120:   ik->initialize(CHECK);
> 121: 
> 122:   TempNewSymbol field_name = SymbolTable::new_symbol("N""ULL");

Why "N""ULL", not "NULL"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2067666542

From liach at openjdk.org  Wed Apr 30 00:41:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 00:41:51 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v11]
In-Reply-To: 
References: 
 
Message-ID: <09zj650ehqrBry34lHCh1KurscjMtrwFO4lQ-ZMiKkE=.c637deda-9acc-4f54-a69e-2aa1df62aec6@github.com>

On Tue, 29 Apr 2025 19:17:02 GMT, Chen Liang  wrote:

>> Some AccessFlag parsing methods throw IAE because a flag mask is not valid in a location. However, there is no easy way to check what flag mask bits or what flags are valid for a location. We need such APIs to check, specific to each class file format version.
>> 
>> Also in the investigation, it's noted that `ACC_SYNTHETIC` is incorrectly represented - it is available since release 5.0 instead of release 7. This bug is fixed together for implementation simplicity.
>> 
>> The new methods are all in `AccessFlag.Location`:
>> - `Set flags()`
>> - `int flagsMask()`
>> - `Set flags(ClassFileFormatVersion)`
>> - `int flagsMask(ClassFileFormatVersion)`
>> 
>> Also there is some simplification to `AccessFlag` itself to remove the anonymous classes, which should be more startup-friendly.
>> 
>> Testing: Tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicit imports

Thanks for the reviews! I think we will reconsider the spliterator flags with all other immutable collections later.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23095#issuecomment-2840535419

From liach at openjdk.org  Wed Apr 30 00:41:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 00:41:52 GMT
Subject: Integrated: 8347471: Provide valid flags and mask in
 AccessFlag.Location
In-Reply-To: 
References: 
Message-ID: <4FeAOgI6Cul-aIFtANrpfi6w_WCpLl9u0G2gfCG10qI=.54a1a61e-70b9-4e0c-bb83-46a6d1f61b48@github.com>

On Tue, 14 Jan 2025 07:38:30 GMT, Chen Liang  wrote:

> Some AccessFlag parsing methods throw IAE because a flag mask is not valid in a location. However, there is no easy way to check what flag mask bits or what flags are valid for a location. We need such APIs to check, specific to each class file format version.
> 
> Also in the investigation, it's noted that `ACC_SYNTHETIC` is incorrectly represented - it is available since release 5.0 instead of release 7. This bug is fixed together for implementation simplicity.
> 
> The new methods are all in `AccessFlag.Location`:
> - `Set flags()`
> - `int flagsMask()`
> - `Set flags(ClassFileFormatVersion)`
> - `int flagsMask(ClassFileFormatVersion)`
> 
> Also there is some simplification to `AccessFlag` itself to remove the anonymous classes, which should be more startup-friendly.
> 
> Testing: Tier 1-3

This pull request has now been integrated.

Changeset: dcffd9d9
Author:    Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/dcffd9d9ac1ad1ed814b5bb45222a25621eeccda
Stats:     721 lines in 9 files changed: 400 ins; 142 del; 179 mod

8347471: Provide valid flags and mask in AccessFlag.Location

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/23095

From iklam at openjdk.org  Wed Apr 30 00:56:19 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 30 Apr 2025 00:56:19 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v8]
In-Reply-To: 
References: 
Message-ID: 

> This PR contains 2 parts
> 
> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.
> 
> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):
> 
> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 
> 
> `ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:
> 
> - If an entry has not yet been collected, we make sure it will never be collected.
> - If an entry has been collected, we remove it from the table
> 
> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.
> 
> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.
> 
> In the future, we may relax the implementation to allow for other use cases.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Renamed the internal field ReferenceQueue.NULL to NULL_QUEUE to avoid failing hotspot/jtreg/sources/TestNoNULL.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24757/files
  - new: https://git.openjdk.org/jdk/pull/24757/files/01f0ea0e..4aa68741

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24757&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24757&range=06-07

  Stats: 14 lines in 3 files changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/24757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24757/head:pull/24757

PR: https://git.openjdk.org/jdk/pull/24757

From iklam at openjdk.org  Wed Apr 30 01:00:55 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 30 Apr 2025 01:00:55 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v7]
In-Reply-To: 
References: 
 
 
Message-ID: <5Ee_fZ26yh7OGsJmsVl38UkBzZJ5n2oo1hHSwZcUX5w=.00046330-64ef-40f0-b078-4e0c756658bd@github.com>

On Wed, 30 Apr 2025 00:28:40 GMT, Zhengyu Gu  wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @fisk comment -- use proper HeapAccess to load referent; Also refactor AOTReferenceObjSupport::is_enabled()
>
> src/hotspot/share/cds/aotReferenceObjSupport.cpp line 122:
> 
>> 120:   ik->initialize(CHECK);
>> 121: 
>> 122:   TempNewSymbol field_name = SymbolTable::new_symbol("N""ULL");
> 
> Why "N""ULL", not "NULL"?

That's because a stand-lone word "NULL" will cause hotspot/jtreg/sources/TestNoNULL.java to fail. I have renamed the internal field to NULL_QUEUE to avoid the failure, per recommendation of @kimbarrett

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2067691778

From asemenyuk at openjdk.org  Wed Apr 30 01:17:50 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 30 Apr 2025 01:17:50 GMT
Subject: Integrated: 8355651: Issues with post-image hook
In-Reply-To: <5RuvuTl0kW-MbAAb0sJb1zkBnWUAnNTHKp2r8wQwiz8=.34a6dd59-aa49-4f51-b128-222e4116e922@github.com>
References: <5RuvuTl0kW-MbAAb0sJb1zkBnWUAnNTHKp2r8wQwiz8=.34a6dd59-aa49-4f51-b128-222e4116e922@github.com>
Message-ID: 

On Sat, 26 Apr 2025 21:31:35 GMT, Alexey Semenyuk  wrote:

> - Add missing "post-image" infrastructure on Linux.
>  - Fix "post-image" infrastructure on macOS and Windows.
>  - Add relevant tests.
>  - Update TKit to support new tests.

This pull request has now been integrated.

Changeset: 1a9a9288
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/1a9a9288a6c1a58e1678cf0abae75bcf84e1f6af
Stats:     930 lines in 16 files changed: 816 ins; 77 del; 37 mod

8355651: Issues with post-image hook

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/24899

From zgu at openjdk.org  Wed Apr 30 01:20:46 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Wed, 30 Apr 2025 01:20:46 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v7]
In-Reply-To: <5Ee_fZ26yh7OGsJmsVl38UkBzZJ5n2oo1hHSwZcUX5w=.00046330-64ef-40f0-b078-4e0c756658bd@github.com>
References: 
 
 
 <5Ee_fZ26yh7OGsJmsVl38UkBzZJ5n2oo1hHSwZcUX5w=.00046330-64ef-40f0-b078-4e0c756658bd@github.com>
Message-ID: 

On Wed, 30 Apr 2025 00:57:51 GMT, Ioi Lam  wrote:

>> src/hotspot/share/cds/aotReferenceObjSupport.cpp line 122:
>> 
>>> 120:   ik->initialize(CHECK);
>>> 121: 
>>> 122:   TempNewSymbol field_name = SymbolTable::new_symbol("N""ULL");
>> 
>> Why "N""ULL", not "NULL"?
>
> That's because a stand-lone word "NULL" will cause hotspot/jtreg/sources/TestNoNULL.java to fail. I have renamed the internal field to NULL_QUEUE to avoid the failure, per recommendation of @kimbarrett

Thank you for the explanation!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2067704580

From duke at openjdk.org  Wed Apr 30 01:26:51 2025
From: duke at openjdk.org (erifan)
Date: Wed, 30 Apr 2025 01:26:51 GMT
Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare
 [v3]
In-Reply-To: <1Qo4pB9I7Ok4ntXSE-KkE0sv-Tp5EVCWriWnjcf2iEE=.a7e28640-85df-436a-9c82-3c067cc88dee@github.com>
References: 
 
 <1Qo4pB9I7Ok4ntXSE-KkE0sv-Tp5EVCWriWnjcf2iEE=.a7e28640-85df-436a-9c82-3c067cc88dee@github.com>
Message-ID: 

On Tue, 29 Apr 2025 10:22:22 GMT, Emanuel Peter  wrote:

> Yes, this discussion is down to `requires` vs `applyIf`. This is my argument for `applyIf`, quoted from above, I have not yet seen an argument against it:
> 
> > If you use @require, then the person does not realize there is a test AND the test is not run. If you use applyIf, the person does not realize there is a test, but it is run at least for result verifiation - and then the person MIGHT realize if the test catches a wrong result / crash.
> 
> In my understanding, `requires` should only be used if the test really **requires** a certain platform or feature. That can be because some flags are only available under certain platforms for example. But for IR tests, we should try to always use `applyIf`, because it allows testing on other platforms.
> 
> Actually, I filed this RFE a while ago: https://bugs.openjdk.org/browse/JDK-8310891 We should try to move as many tests from using `requires` to `applyIf`, so that we have an increased test coverage.

I see, I'll update the code. Thanks~

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-2840582699

From duke at openjdk.org  Wed Apr 30 03:00:06 2025
From: duke at openjdk.org (duke)
Date: Wed, 30 Apr 2025 03:00:06 GMT
Subject: Withdrawn: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner
In-Reply-To: 
References: 
Message-ID: <6ZMMV6FCI2iePRwwx6SFJiPJnyKRsUZX6uWK52XIRPE=.9212df0c-0f7c-47f8-800c-6bb83c96d06d@github.com>

On Fri, 15 Nov 2024 20:54:56 GMT, Aleksey Shipilev  wrote:

> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer.
> 
> We can migrate DBBs to use `java.lang.ref.Cleaner`.
> 
> There are two pecularities during this rewrite.
> 
> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it.
> 
> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us.
> 
> Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. This is why we need another way to check progress that involves checking if cleaner has acted.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/nio java/io`
>  - [x] Linux AArch64 server fastdebug, `java/nio java/io`
>  - [x] Linux x86_64 server fastdebug, `all`
>  - [x] Linux AArch64 server fastdebug, `all`

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/22165

From syan at openjdk.org  Wed Apr 30 03:24:51 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 30 Apr 2025 03:24:51 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v3]
In-Reply-To: 
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 
Message-ID: 

On Mon, 28 Apr 2025 14:36:33 GMT, Chen Liang  wrote:

>> Perf numbers for simple main:
>> Linking of `Class::forName0` down from ~152 to ~83
>> 
>> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
>> JNI: ~45
>> baseline panama: ~164
>> patch: ~103
>> 
>> Also see #24705.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
>  - Use more simple function descriptor
>  - Simplify FFM linker warmup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
>  - Wip work trying to speed up FFM

This PR cause linux-riscv64 cross build fails.


# /tmp/tone/run/jtreg/jdk-repo/build/linux-riscv64-server-release/support/interim-image/bin/java -Xint -XX:DumpLoadedClassList=/tmp/tone/run/jtreg/jdk-repo/build/linux-riscv64-server-release/support/link_opt/classlist.raw -Duser.language=en -Duser.country=US -cp /tmp/tone/run/jtreg/jdk-repo/build/linux-riscv64-server-release/support/classlist.jar build.tools.classlist.HelloClasslist
hello
world!
from: 
localhost/127.0.0.1
WARNING: A restricted method in java.lang.foreign.Linker has been called
WARNING: java.lang.foreign.Linker::downcallHandle has been called by build.tools.classlist.HelloClasslist in an unnamed module (file:/tmp/tone/run/jtreg/jdk-repo/build/linux-riscv64-server-release/support/classlist.jar)
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f46e794c5f1, pid=284260, tid=284261
#
# JRE version: OpenJDK Runtime Environment (25.0) (build 25-internal-83d0bd85)
# Java VM: OpenJDK 64-Bit Server VM (25-internal-83d0bd85, interpreted mode, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x79b5f1]  ForeignGlobals::parse_abi_descriptor(_jobject*)+0x1d1
#
# Core dump will be written. Default location: /tmp/tone/run/jtreg/jdk-repo/core.284260
#
# An error report file with more information is saved as:
# /tmp/tone/run/jtreg/jdk-repo/hs_err_pid284260.log

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24742#issuecomment-2840702669

From liach at openjdk.org  Wed Apr 30 03:53:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 03:53:52 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v3]
In-Reply-To: 
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 
Message-ID: 

On Mon, 28 Apr 2025 14:36:33 GMT, Chen Liang  wrote:

>> Perf numbers for simple main:
>> Linking of `Class::forName0` down from ~152 to ~83
>> 
>> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
>> JNI: ~45
>> baseline panama: ~164
>> patch: ~103
>> 
>> Also see #24705.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
>  - Use more simple function descriptor
>  - Simplify FFM linker warmup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
>  - Wip work trying to speed up FFM

Hmm, is this a latent bug in ffm's riscv implementation? I saw a crash but had no hserrpid log for it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24742#issuecomment-2840730989

From duke at openjdk.org  Wed Apr 30 04:04:46 2025
From: duke at openjdk.org (duke)
Date: Wed, 30 Apr 2025 04:04:46 GMT
Subject: RFR: 8342886: Update MET timezone in TimeZoneNames files [v5]
In-Reply-To: 
References: 
 
Message-ID: <2CpRYM735S1VwXyczwCGJC1wjg4-rYe9uROjqvx4Z3E=.8a12ea9f-c9fc-4121-b3ef-d7266cfb6f6c@github.com>

On Tue, 29 Apr 2025 18:11:05 GMT, Gautham Krishnan  wrote:

>> MET timezone entry in TimeZoneNames.java and TimeZoneNames_*.java needs to be updated as MET is alias to Europe/Brussels as per 2024b tzdata changes.
>> 
>> Also Bug4848242.java needs to be removed as the test expects all euro locale time zones should have the same short names.
>
> Gautham Krishnan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/sun/util/resources/TimeZone/Bug4848242.java
>   
>   Co-authored-by: Naoto Sato 

@gauthamkrishnanibm 
Your change (at version 30e2c54a1aa1a41a0dc7cdc555857eed4def8845) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24871#issuecomment-2840742566

From alanb at openjdk.org  Wed Apr 30 06:10:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Apr 2025 06:10:52 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value [v4]
In-Reply-To: 
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
 
 
 
 
Message-ID: 

On Tue, 29 Apr 2025 18:27:45 GMT, Brian Burkhalter  wrote:

>> Perhaps the `@requires` tag is no longer needed. Without it, this test passed 30 repeats in the CI on both Intel and ARM Linux nodes.
>
> Comment simplified in 4cee3c2.

Okay, just a bit puzzled as to why it doesn't run on Linux. The VM uses setrlimit(RLIMIT_NOFILE) to set the limit to the hard limit (rlim_max). So is the issue here that the hard limit less than 2050 on some test systems?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24860#discussion_r2067914267

From pminborg at openjdk.org  Wed Apr 30 06:30:13 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Apr 2025 06:30:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v78]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 29 Apr 2025 14:51:08 GMT, Jorn Vernee  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make public constuctor private
>
> test/jdk/java/lang/StableValue/StableFunctionTest.java line 79:
> 
>> 77:     void factoryInvariants(Set inputs) {
>> 78:         assertThrows(NullPointerException.class, () -> StableValue.function(null, MAPPER));
>> 79:         assertThrows(NullPointerException.class, () -> StableValue.function(inputs, null));
> 
> I think you also need a case for `null` elements in `inputs`

There is a separate `@Test void nullKeys()` that takes care of that case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2067935980

From vyazici at openjdk.org  Wed Apr 30 06:51:24 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 30 Apr 2025 06:51:24 GMT
Subject: RFR: 8355391: Use Long::hashCode in java.time
Message-ID: <35NfgP2ueIq0RkDomVTj7bLtM_R-qD7spwbhpIXNFZA=.99fab560-5969-4a75-9212-52626a3e5b62@github.com>

Replace manual bitwise operations in `hashCode` implementations of `java.time` with `Long::hashCode`.

-------------

Commit messages:
 - Use `Long::hashCode`

Changes: https://git.openjdk.org/jdk/pull/24959/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24959&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355391
  Stats: 12 lines in 5 files changed: 0 ins; 5 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24959.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24959/head:pull/24959

PR: https://git.openjdk.org/jdk/pull/24959

From syan at openjdk.org  Wed Apr 30 07:01:51 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 30 Apr 2025 07:01:51 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v3]
In-Reply-To: 
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 
Message-ID: 

On Mon, 28 Apr 2025 14:36:33 GMT, Chen Liang  wrote:

>> Perf numbers for simple main:
>> Linking of `Class::forName0` down from ~152 to ~83
>> 
>> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
>> JNI: ~45
>> baseline panama: ~164
>> patch: ~103
>> 
>> Also see #24705.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
>  - Use more simple function descriptor
>  - Simplify FFM linker warmup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
>  - Wip work trying to speed up FFM

[hs_err_pid192741.log](https://github.com/user-attachments/files/19972563/hs_err_pid192741.log)
[hs_err_pid284285.log](https://github.com/user-attachments/files/19972565/hs_err_pid284285.log)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24742#issuecomment-2840998318

From pminborg at openjdk.org  Wed Apr 30 07:38:39 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Apr 2025 07:38:39 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
> 
> Re-allocated segments are not zeroed between allocations.

Per Minborg 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 nine additional commits since the last revision:

 - Break out stress thest and ProblemList it on macosx
 - Merge branch 'master' into internal-allocator
 - Remove interface level
 - Add benchmark class with virtual executor
 - Add rudimentary documentation
 - Convert class to record and add @ForceInline
 - Refactor and add benchmark
 - Merge branch 'master' into internal-allocator
 - Change set from previous PR

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24829/files
  - new: https://git.openjdk.org/jdk/pull/24829/files/59e1f261..1e9d0460

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24829&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24829&range=00-01

  Stats: 25178 lines in 770 files changed: 17686 ins; 4783 del; 2709 mod
  Patch: https://git.openjdk.org/jdk/pull/24829.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24829/head:pull/24829

PR: https://git.openjdk.org/jdk/pull/24829

From pminborg at openjdk.org  Wed Apr 30 07:50:34 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Apr 2025 07:50:34 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
> 
> Re-allocated segments are not zeroed between allocations.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Convert to junit tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24829/files
  - new: https://git.openjdk.org/jdk/pull/24829/files/1e9d0460..101882d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24829&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24829&range=01-02

  Stats: 30 lines in 2 files changed: 3 ins; 2 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/24829.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24829/head:pull/24829

PR: https://git.openjdk.org/jdk/pull/24829

From aturbanov at openjdk.org  Wed Apr 30 08:02:50 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 30 Apr 2025 08:02:50 GMT
Subject: RFR: 8351000: StringBuilder getChar and putChar robustness
In-Reply-To: 
References: 
Message-ID: <6RUMsWawuFwZ8W1GboI__qwrHeMRI8UizIEoASehG2Q=.58870648-5216-4afc-b5a8-c8ae46884a92@github.com>

On Tue, 29 Apr 2025 14:10:30 GMT, Roger Riggs  wrote:

> Improve StringBuilder getChar and putChar robustness with racy updates to StringBuilder. 
> Test racing threads with append, insert, and reading characters.

test/jdk/java/lang/StringBuilder/RacingSBThreads.java line 61:

> 59:     // Constant arguments available to be passed to StringBuilder operations
> 60:     private static final StringBuilder otherSB = new StringBuilder("ab\uFF21\uFF22");
> 61:     private static final CharBuffer otherCharBuffer = CharBuffer.allocate(4).append("a\uFF21");

unused field

test/jdk/java/lang/StringBuilder/RacingSBThreads.java line 85:

> 83:      * Run the stress cases indicated by command line arguments or run all cases.
> 84:      * Running each for TIMEOUT_SEC seconds or until a failure.
> 85:      * The timeuut/test duration can be scaled by setting System property

Suggestion:

     * The timeout/test duration can be scaled by setting System property

test/jdk/java/lang/StringBuilder/RacingSBThreads.java line 158:

> 156:             this.func = func;
> 157:             this.sbInitString = sbInitString;
> 158:         };

Suggestion:

        }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24951#discussion_r2068110759
PR Review Comment: https://git.openjdk.org/jdk/pull/24951#discussion_r2068109643
PR Review Comment: https://git.openjdk.org/jdk/pull/24951#discussion_r2068110062

From aboldtch at openjdk.org  Wed Apr 30 08:52:50 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 30 Apr 2025 08:52:50 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 30 Apr 2025 00:56:19 GMT, Ioi Lam  wrote:

>> This PR contains 2 parts
>> 
>> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
>> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.
>> 
>> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):
>> 
>> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
>> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 
>> 
>> `ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:
>> 
>> - If an entry has not yet been collected, we make sure it will never be collected.
>> - If an entry has been collected, we remove it from the table
>> 
>> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.
>> 
>> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.
>> 
>> In the future, we may relax the implementation to allow for other use cases.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renamed the internal field ReferenceQueue.NULL to NULL_QUEUE to avoid failing hotspot/jtreg/sources/TestNoNULL.java

lgtm. Just a few comments.

src/hotspot/share/cds/aotArtifactFinder.cpp line 77:

> 75:   // into the AOT cache -- that will be decided by the code below.
> 76:   SystemDictionaryShared::finish_exclusion_checks();
> 77:   AOTReferenceObjSupport::init_keep_alive_objs_table();

This should be guarded with `INCLUDE_CDS_JAVA_HEAP` somehow. I guess the cleanest way would be to use `NOT_CDS_JAVA_HEAP_RETURN` in `aotReferenceObjSupport.hpp`

src/hotspot/share/cds/aotReferenceObjSupport.cpp line 95:

> 93: #if INCLUDE_CDS_JAVA_HEAP
> 94: 
> 95: 

Suggestion:

test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/WeakReferenceTest.java line 233:

> 231:         if (ref2.get() == null) {
> 232:             throw new RuntimeException("ref2.get() should not be null");
> 233:         }

The referent of ref2 is never strong. If a GC occurs between makeRef2() and this check, we could hit this Exception. The test should either keep it strongly reachable until after this check or just not test wether it is reachable before the call to System.gc().

-------------

PR Review: https://git.openjdk.org/jdk/pull/24757#pullrequestreview-2806261263
PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2068189381
PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2068186097
PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2068180118

From shade at openjdk.org  Wed Apr 30 09:07:48 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Apr 2025 09:07:48 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 26 Mar 2025 17:31:47 GMT, Aleksey Shipilev  wrote:

>> When jspawnhelper fails for whatever reason, but more prominently due to [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the errors into stdout, but not to the relevant `IOException`. So, if the application is configured to only capture the exception logs (e.g. through `java.util.logging`), we will miss any output from `jspawnhelper`, and user would be left without a clue what have happened. We have seen customers spending weeks trying to figure out what went wrong.
>> 
>> It would be good to provide useful `IOException` when `jspawnhelper` fails. We already have a precedent with vmError [printing helpful suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) when VM fails, we can do a similar thing here. 
>> 
>> I am very open to bike-shedding about the actual message :)
>> 
>> Additional testing:
>>  - [x] Ad-hoc experiments with breaking jspawnhelper
>>  - [x] macos-aarch64-server-fastdebug, `java/lang/Process java/lang/ProcessBuilder`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pull message into a field

Friendly ping. @RogerRiggs, maybe?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24149#issuecomment-2841306699

From vklang at openjdk.org  Wed Apr 30 09:16:50 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 30 Apr 2025 09:16:50 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v10]
In-Reply-To: <78kIw0fEwr28hUJiXvzVtzJiU45h92XUYbLOMJVx-qU=.41829434-dc66-4f8d-9eb4-b10948f3a2b2@github.com>
References: 
 <78kIw0fEwr28hUJiXvzVtzJiU45h92XUYbLOMJVx-qU=.41829434-dc66-4f8d-9eb4-b10948f3a2b2@github.com>
Message-ID: 

On Tue, 29 Apr 2025 19:03:08 GMT, Chen Liang  wrote:

>> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
>> 
>> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
>> 
>> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
>> 
>> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.
>
> 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 17 additional commits since the last revision:
> 
>  - Rewrite impl to follow the new simplified spec
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - Try to simplify the model - use the finish of computeValue
>    
>  - Test updates - remove repetition, test case for no stale installation
>  - Fix incorrect promise removal when unnecessary and add regression test
>  - Cannot test for recursion eagerly - add test case
>  - More spec, eager exception, finish with existing, thanks John
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - docs
>  - Remove the throwing behavior due to shallow reentrancy
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/bde12d99...221d51e7

src/java.base/share/classes/java/lang/ClassValue.java line 89:

> 87:      * not attempt to associate a value, and may terminate either by returning
> 88:      * an observed associated value, if it exists, or by propagating that
> 89:      * exception.

Does this mean that exceptions may be swallowed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2068233456

From dfuchs at openjdk.org  Wed Apr 30 10:19:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 30 Apr 2025 10:19:54 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v3]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement 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 411 commits:

 - merge latest changes from master branch
 - http3: jep review feedback: rename HttpRequest.HttpRequestOption into top-level HttpOption. Http3DiscoveryMode is now an inner class in HttpOption. Improved protocol selection documentation in HttpClient class-level apiNote. Add links from Builder.version methods.
 - merge latest changes from master branch
 - http3: add missing 
 separator to Http3DiscoveryMode.ALT_SVC API documentation
 - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
 - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
 - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
 - http3: minor improvement to log message
 - http3: Artur's review - remove commented out code from test
 - http3: Artur's review - make methods package private
 - ... and 401 more: https://git.openjdk.org/jdk/compare/c2485d5f...dfa26044

-------------

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=02
  Stats: 102863 lines in 472 files changed: 100230 ins; 1120 del; 1513 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 jvernee at openjdk.org  Wed Apr 30 10:53:01 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 30 Apr 2025 10:53:01 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v3]
In-Reply-To: 
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 
Message-ID: 

On Mon, 28 Apr 2025 14:36:33 GMT, Chen Liang  wrote:

>> Perf numbers for simple main:
>> Linking of `Class::forName0` down from ~152 to ~83
>> 
>> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
>> JNI: ~45
>> baseline panama: ~164
>> patch: ~103
>> 
>> Also see #24705.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
>  - Use more simple function descriptor
>  - Simplify FFM linker warmup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
>  - Wip work trying to speed up FFM

That stack trace is showing that we're going through the `LinuxRISCV64CallArranger`, but I wonder if we are ending up in the `ForeignGlobals::parse_abi_descriptor` of another platform? That would result in a mismatch between the kind of ABIDescriptor which the Java code passes, and the one which the VM code expects.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24742#issuecomment-2841582780

From jvernee at openjdk.org  Wed Apr 30 10:55:10 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 30 Apr 2025 10:55:10 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v78]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 24 Apr 2025 10:37:59 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make public constuctor private

The other comments I had weren't as important

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23972#pullrequestreview-2806662052

From pminborg at openjdk.org  Wed Apr 30 10:55:41 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Apr 2025 10:55:41 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v4]
In-Reply-To: 
References: 
Message-ID: 

> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
> 
> Re-allocated segments are not zeroed between allocations.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add test coverage and add convenience methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24829/files
  - new: https://git.openjdk.org/jdk/pull/24829/files/101882d5..b1b84282

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24829&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24829&range=02-03

  Stats: 340 lines in 3 files changed: 331 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/24829.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24829/head:pull/24829

PR: https://git.openjdk.org/jdk/pull/24829

From tschatzl at openjdk.org  Wed Apr 30 11:21:41 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 30 Apr 2025 11:21:41 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v37]
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:

  * ayang review: remove sweep_epoch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/51dfbe54..8b568806

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=35-36

  Stats: 21 lines in 4 files changed: 0 ins; 15 del; 6 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  Wed Apr 30 11:27:44 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Apr 2025 11:27:44 GMT
Subject: RFR: 8355938: Addressed rare lost unpark bug 8074773 by
 pre-loading LockSupport.class
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 19:02:20 GMT, Chen Liang  wrote:

> The bug description seems like it is a fault in the JVM implementation - if that is the case, a core library bypass is unreliable, as such faults might happen to other classes and cause other consequences; and we might need to fix it from the VM runtime or compiler side, as the original report implies.

It seems to about nested parking that can arise with the first use of LockSupport.park from a class with a defining class loader that is not the boot loader. The first usage, say an invokestatic to call the park method, will call the loadClass on caller's defining class loader.  For the app class loader, and many other custom class loaders, that are parallel capable, then there will be a CHM to support the mapping of class names to locks. Contention on the CHM seems to have lead to the nested park.  CHM and a lot of other code has changed since and not clear that it will duplicate easily now. Martin's ParkLoops test from the 2015 issue is in the test tree but it might be that a variant of this that uses a custom class loader that overrides getClassLoadingLock or parks in loadClass might be able to trigger it. As a custom class loader's loadClass can do anything then it almost feels like creating a class loader needs it have it recorded immediately as an initiating class loader. Hopef
 ully David will remember more of this when he gets back.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24952#issuecomment-2841672692

From aturbanov at openjdk.org  Wed Apr 30 11:32:47 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 30 Apr 2025 11:32:47 GMT
Subject: RFR: 8351000: StringBuilder getChar and putChar robustness
In-Reply-To: 
References: 
Message-ID: 

On Tue, 29 Apr 2025 14:10:30 GMT, Roger Riggs  wrote:

> Improve StringBuilder getChar and putChar robustness with racy updates to StringBuilder. 
> Test racing threads with append, insert, and reading characters.

Let's cleanup test a bit

-------------

Changes requested by aturbanov (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24951#pullrequestreview-2806744000

From jpai at openjdk.org  Wed Apr 30 11:56:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Apr 2025 11:56:55 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v3]
In-Reply-To: 
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 
Message-ID: <739SLqLEFntDDn7vzGDUZ5UwDRjknvC7ruVBZKi8qek=.270dc887-fbe9-4f9a-8fc3-f38688957389@github.com>

On Mon, 28 Apr 2025 14:36:33 GMT, Chen Liang  wrote:

>> Perf numbers for simple main:
>> Linking of `Class::forName0` down from ~152 to ~83
>> 
>> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
>> JNI: ~45
>> baseline panama: ~164
>> patch: ~103
>> 
>> Also see #24705.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
>  - Use more simple function descriptor
>  - Simplify FFM linker warmup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
>  - Wip work trying to speed up FFM

For the changes in `HelloClasslist`, I think it would even need a change in the build file. With the changes in this PR, I'm now seeing the following (platform runtime) warnings when building the JDK:


WARNING: A restricted method in java.lang.foreign.Linker has been called
WARNING: java.lang.foreign.Linker::downcallHandle has been called by build.tools.classlist.HelloClasslist in an unnamed module (file:.../build/macosx-aarch64/support/classlist.jar)
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24742#issuecomment-2841733865

From rehn at openjdk.org  Wed Apr 30 12:00:45 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 30 Apr 2025 12:00:45 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v4]
In-Reply-To: 
References: 
Message-ID: 

> Hi, for you to consider.
> 
> These tests constantly fails in qemu-user.
> Either the require host to be same arch explicit or implicit (sysroot).
> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'" for SA tests.
> 
> From bug:
>> qemu-user/rv64 sets uarch to "qemu" in /proc/cpuinfo (qemu-system do not do that).
>> We add this uarch to CPU feature string.
>> This means we can use jtreg 'require' with cpu string to filter out tests in qemu-user.
> 
> Relevant qemu code:
> https://github.com/qemu/qemu/blob/170825d14d88a1ce7fae98d5a928480f2f329b22/linux-user/riscv/target_proc.h#L29
> 
> Relevant hotspot code:
> https://github.com/openjdk/jdk/blob/fa0b18bfde38ee2ffbab33a9eaac547fe8aa3c7c/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L250
> 
> Tested that the require only filters out tests in qemu+riscv64.
> 
> Thanks!
> 
> /Robbin

Robbin Ehn 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 branch 'master' into qemu-user-issues
 - Merge branch 'master' into qemu-user-issues
 - Revert
 - Merge branch 'master' into qemu-user-issues
 - Merge branch 'master' into qemu-user-issues
 - more
 - more
 - native or very long

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24229/files
  - new: https://git.openjdk.org/jdk/pull/24229/files/73968ab8..5668fe13

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24229&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24229&range=02-03

  Stats: 302323 lines in 2847 files changed: 92525 ins; 199451 del; 10347 mod
  Patch: https://git.openjdk.org/jdk/pull/24229.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24229/head:pull/24229

PR: https://git.openjdk.org/jdk/pull/24229

From rehn at openjdk.org  Wed Apr 30 12:00:47 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 30 Apr 2025 12:00:47 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v3]
In-Reply-To: <5sujqD7L_cmLUyDwYb4PhgOlEeiFwlkAV7RJoVMFTrM=.223437cd-bbb2-4ef3-a6fe-b13ce402e14b@github.com>
References: 
 <5sujqD7L_cmLUyDwYb4PhgOlEeiFwlkAV7RJoVMFTrM=.223437cd-bbb2-4ef3-a6fe-b13ce402e14b@github.com>
Message-ID: 

On Mon, 31 Mar 2025 10:45:54 GMT, Robbin Ehn  wrote:

>> Hi, for you to consider.
>> 
>> These tests constantly fails in qemu-user.
>> Either the require host to be same arch explicit or implicit (sysroot).
>> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'" for SA tests.
>> 
>> From bug:
>>> qemu-user/rv64 sets uarch to "qemu" in /proc/cpuinfo (qemu-system do not do that).
>>> We add this uarch to CPU feature string.
>>> This means we can use jtreg 'require' with cpu string to filter out tests in qemu-user.
>> 
>> Relevant qemu code:
>> https://github.com/qemu/qemu/blob/170825d14d88a1ce7fae98d5a928480f2f329b22/linux-user/riscv/target_proc.h#L29
>> 
>> Relevant hotspot code:
>> https://github.com/openjdk/jdk/blob/fa0b18bfde38ee2ffbab33a9eaac547fe8aa3c7c/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L250
>> 
>> Tested that the require only filters out tests in qemu+riscv64.
>> 
>> Thanks!
>> 
>> /Robbin
>
> Robbin Ehn 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' into qemu-user-issues
>  - Revert
>  - Merge branch 'master' into qemu-user-issues
>  - Merge branch 'master' into qemu-user-issues
>  - more
>  - more
>  - native or very long

I don't see any alternatives - if this approach is not liked,  any suggestions?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2841743196

From liach at openjdk.org  Wed Apr 30 12:04:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 12:04:52 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v10]
In-Reply-To: 
References: 
 <78kIw0fEwr28hUJiXvzVtzJiU45h92XUYbLOMJVx-qU=.41829434-dc66-4f8d-9eb4-b10948f3a2b2@github.com>
 
Message-ID: 

On Wed, 30 Apr 2025 09:14:20 GMT, Viktor Klang  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 17 additional commits since the last revision:
>> 
>>  - Rewrite impl to follow the new simplified spec
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>>  - Try to simplify the model - use the finish of computeValue
>>    
>>  - Test updates - remove repetition, test case for no stale installation
>>  - Fix incorrect promise removal when unnecessary and add regression test
>>  - Cannot test for recursion eagerly - add test case
>>  - More spec, eager exception, finish with existing, thanks John
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>>  - docs
>>  - Remove the throwing behavior due to shallow reentrancy
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/200c663e...221d51e7
>
> src/java.base/share/classes/java/lang/ClassValue.java line 89:
> 
>> 87:      * not attempt to associate a value, and may terminate either by returning
>> 88:      * an observed associated value, if it exists, or by propagating that
>> 89:      * exception.
> 
> Does this mean that exceptions may be swallowed?

Yes, if a value is discovered to be associated when an exception from computeValue was trying to be thrown.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2068522904

From jpai at openjdk.org  Wed Apr 30 12:02:25 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Apr 2025 12:02:25 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v7]
In-Reply-To: 
References: 
Message-ID: <7-hlRi4K3O2f8GbvfOy7Znvvgwyr8pP9BRaIIn4yikM=.1abe74c0-ac9c-447a-956e-49c2d5a93c39@github.com>

> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.
> 
> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.
> 
> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.
> 
> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.
> 
> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.
> 
> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now maintained in the `ZipFile`,...

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 21 additional commits since the last revision:

 - Eirik's review about code comments
 - fix comment typo
 - merge latest from master branch
 - 8355975: introduce a test for 8355975
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - improve code comment for ZipFile.zipCoder
 - ... and 11 more: https://git.openjdk.org/jdk/compare/bfa4438c...9a29b960

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23986/files
  - new: https://git.openjdk.org/jdk/pull/23986/files/4e3f8e70..9a29b960

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23986&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23986&range=05-06

  Stats: 368006 lines in 4489 files changed: 111658 ins; 239302 del; 17046 mod
  Patch: https://git.openjdk.org/jdk/pull/23986.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23986/head:pull/23986

PR: https://git.openjdk.org/jdk/pull/23986

From jpai at openjdk.org  Wed Apr 30 12:11:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Apr 2025 12:11:51 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 24 Mar 2025 12:52:49 GMT, Eirik Bj?rsn?s  wrote:

>> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - improve code comment for ZipFile.zipCoder
>>  - Alan's suggestion - change code comment about Source class being thread safe
>>  - Alan's suggestion - trim the javadoc of (internal) ZipCoder class
>
> src/java.base/share/classes/java/util/zip/ZipCoder.java line 181:
> 
>> 179: 
>> 180:     /**
>> 181:      * {@return the {@link Charset} used this {@code ZipCoder}}
> 
> Suggestion:
> 
>      * {@return the {@link Charset} used by this {@code ZipCoder}}

Fixed.

> src/java.base/share/classes/java/util/zip/ZipFile.java line 85:
> 
>> 83:     private final String filePath;     // ZIP file path
>> 84:     private final String fileName;     // name of the file
>> 85:     // ZipCoder for entry names and comments when not using UTF-8
> 
> "_when not using  UTF-8_"  could be confusing.
> 
> The ZipCoder here may well be UTF-8, it's more about the entry not mandating UTF-8 by having its language encoding flag set.
> 
> I think we should either clearly explain when this ZipCoder is used (when entries do not mandate UTF-8), or drop the information here and lean on it being explained in `zipCoderFor`.
> 
> If we decide to drop it, this could be just:
> 
> `// Used when decoding entry names and comments`
> 
> If we decide to keep it, then something like:
> 
> `// Used when decoding entry names and comments, unless entry flags mandate UTF-8`

I used your suggestion of "Used when decoding entry names and comments" to keep it simple.

> src/java.base/share/classes/java/util/zip/ZipFile.java line 1145:
> 
>> 1143:     static record EntryPos(String name, int pos) {}
>> 1144: 
>> 1145:     // Implementation note: This class is be thread safe.
> 
> Suggestion:
> 
>     // Implementation note: This class is thread safe.

Fixed

> src/java.base/share/classes/java/util/zip/ZipFile.java line 1432:
> 
>> 1430:          * where a ZIP file is re-opened after it has been modified).
>> 1431:          * - The Charset, that was provided when constructing a ZipFile instance,
>> 1432:          * for reading non-UTF-8 entry names and comments.
> 
> I think it would be sufficient to say "The Charset that was provided when constructing the ZipFile instance". Any non-UTF8-ness is better explained  elsewhere.

Fixed

> src/java.base/share/classes/java/util/zip/ZipFile.java line 1438:
> 
>> 1436:             private final BasicFileAttributes attrs;
>> 1437:             private final File file;
>> 1438:             // the Charset to be used for processing non-UTF-8 entry names in the ZIP file
> 
> Similarly this could just say "The Charset that was provided when constructing the ZipFile instance"

Yes, I think your suggested comment is good. I've updated the PR to use this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2068530939
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2068531394
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2068531636
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2068531991
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2068533150

From jpai at openjdk.org  Wed Apr 30 12:11:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Apr 2025 12:11:52 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 24 Mar 2025 01:00:34 GMT, Chen Liang  wrote:

>> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - improve code comment for ZipFile.zipCoder
>>  - Alan's suggestion - change code comment about Source class being thread safe
>>  - Alan's suggestion - trim the javadoc of (internal) ZipCoder class
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 1145:
> 
>> 1143:     static record EntryPos(String name, int pos) {}
>> 1144: 
>> 1145:     // Implementation note: This class is be thread safe.
> 
> Should we comment that this class has no observable state in addition to being thread safe?

Hello Chen, this class does contain state and is allowed to contain state as long as it is thread safe. So I think the current brief comment is enough.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2068530664

From jpai at openjdk.org  Wed Apr 30 12:11:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Apr 2025 12:11:53 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v2]
In-Reply-To: 
References: 
 
 <1aDEYvZqhjpU8GKqVGAZXqqL9wSY711AF_sfCmhUD68=.b98c6bf3-5b78-49a1-b934-93b135395a15@github.com>
 
 <5SCAZb6f9f9ZAPpVfUMOfBdctwfczvQ3effqbDX73cg=.7bd08fb9-a723-4cde-8f6c-ee2f4ea61ef6@github.com>
 
Message-ID: <9UXafhOZm046n5DgB9tyTu3Yw8U5w8sT5x9QCHpQsvI=.b0cc3d0b-bdb0-4d55-bbb9-3f80992423ae@github.com>

On Sun, 23 Mar 2025 10:45:28 GMT, Eirik Bj?rsn?s  wrote:

>> Hello Jaikiran,
>> 
>> Before this change, two ZipFile instances opened using different (non-UTF-8) charsets would have equal keys, and thus be backed by the same Source and ZipCoder instance, whichever ZipFile constructed first would "win".
>> 
>> This seems like a separate bug,  independent of the concurrency concerns described  JDK-8347712.
>> 
>> For the benefit of future maintainers, I think this independent bug should be described in a separate JBS issue.
>> 
>> The bug could be solved in a separate PR, however I feel it's also ok to fix it in this PR, since moving the ZipCoder instance to ZipFile seems to incidentally solve the issue as well.
>> 
>> WDYT?
>
>> This seems like a separate bug, independent of the concurrency concerns described JDK-8347712.
> 
> Consider the following test, which when added to `ZipCoding.java` fails in master but succeeds in this PR:
> 
> 
> /**
>  * Verifies that opening a ZipFile with an incorrect charset does not
>  * prevent a later opening of the same file using the correct charset.
>  *
>  * This may happen if the two ZipFile instances have identical
>  * ZipFile.Source.Key, thus mapping to the same Source instance.
>  *
>  * @throws IOException if an unexpected I/O error occurs
>  */
> @Test
> public void differentNonUTF8Charsets() throws IOException {
>     // Using ISO-8859-15 and ISO-8859-1 here, since they are similar
>     // encodings with different characters for some bytes
> 
>     // The byte 0xA4 is "Euro sign" in 8859-15, "Currency sign (generic)" in 8859-1
>     String euroSign = "\u20AC";
>     String currencySign = "\u00A4";
> 
>     // Create a ZIP, encoded in ISO-8859-15
>     byte[] zip = createZIP("ISO-8859-15", euroSign, euroSign);
>     Path f = Path.of("zf-non-utf.zip");
>     Files.write(f, zip);
> 
>     // Open a ZipFile instance using (incorrect) encoding ISO-8859-1
>     // Then open a ZipFile instance using (correct) encoding ISO-8859-15
>     try (ZipFile incorrect = new ZipFile(f.toFile(), StandardCharsets.ISO_8859_1);
>          ZipFile correct = new ZipFile(f.toFile(), Charset.forName("ISO-8859-15"))) {
> 
>         // Correct encoding should resolve euro sign
>         assertNotNull(correct.getEntry(euroSign));
>         // Correct encoding should not resolve currency sign
>         assertNull(correct.getEntry(currencySign));
> 
>         // Incorrect encoding should resolve currency sign
>         assertNotNull(incorrect.getEntry(currencySign));
>         // Incorrect encoding should not resolve euro sign
>         assertNull(incorrect.getEntry(euroSign));
>     }
> }

Hello Eirik,

> Before this change, two ZipFile instances opened using different (non-UTF-8) charsets would have equal keys, and thus be backed by the same Source and ZipCoder instance, whichever ZipFile constructed first would "win".
> This seems like a separate bug, independent of the concurrency concerns described JDK-8347712.
> For the benefit of future maintainers, I think this independent bug should be described in a separate JBS issue.

That's right - when fixing 8347712 I saw this issue with `Key` class and addressed it in this PR. You have a good point that having a JBS issue specifically for this will be useful. I have now created https://bugs.openjdk.org/browse/JDK-8355975 and linked that issue in this current PR. What helped was your test case example that uses `ISO-8859-15` and `ISO-8859-1` charsets to trigger this issue. I wasn't aware of that difference between `ISO-8859-15` and `ISO-8859-1` charsets. Thank you, I've now added that test in this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2068528308

From alanb at openjdk.org  Wed Apr 30 12:15:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Apr 2025 12:15:53 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v3]
In-Reply-To: 
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 
Message-ID: 

On Mon, 28 Apr 2025 14:36:33 GMT, Chen Liang  wrote:

>> Perf numbers for simple main:
>> Linking of `Class::forName0` down from ~152 to ~83
>> 
>> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
>> JNI: ~45
>> baseline panama: ~164
>> patch: ~103
>> 
>> Also see #24705.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
>  - Use more simple function descriptor
>  - Simplify FFM linker warmup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
>  - Wip work trying to speed up FFM

Yes, it seems that make/GenerateLinkOptData.gmk was missed. JDK-8355971 was created to track this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24742#issuecomment-2841781116

From jpai at openjdk.org  Wed Apr 30 12:23:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Apr 2025 12:23:54 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v6]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 24 Mar 2025 15:01:09 GMT, Eirik Bj?rsn?s  wrote:

>> src/java.base/share/classes/java/util/zip/ZipCoder.java line 44:
>> 
>>> 42:  * 

>>> 43:  * The {@code ZipCoder} for UTF-8 charset is thread safe, {@code ZipCoder}
>>> 44:  * for other charsets require external synchronization.
>> 
>> I think the "thread safe" feature is already implied by the comment on UTF8: "Encoding/decoding is stateless". So I recommend just mentioning that a ZipCoder may carry states, and a ZipCoder obtained from `ZipCoder.get` should only be used locally.
>
> I agree with @liach here. The fact that one ZipCoder is stateless and thread-safe is a class-internal implementation detail and not information which any call site of this API makes use of.

> So I recommend just mentioning that a ZipCoder may carry states, and a ZipCoder obtained from ZipCoder.get should only be used locally.

The `UTF8ZipCoder` may not just be accessed through the `ZipCoder.UTF8` field. It could even be obtained through `ZipCoder.get(UTF_8)`. So the ZipCode returned by `ZipCoder.get()` can still be used concurrently (if it is for UTF-8).

> The fact that one ZipCoder is stateless and thread-safe is a class-internal implementation detail and not information which any call site of this API makes use of.

The `ZipCoder` itself is an internal implementation detail (it's a package protected class), so the javadoc that we are discussing here won't be published by the `java.base` module. I believe that the thread safety aspect of the ZipCoder instances, even if it for some specific charsets, is an important detail even for internal call sites to be aware of. In fact, the current issue that we are fixing shows that this detail might have helped prevent this issue.

I think the brief comment that we have added here, in its current form, is good enough. So unless either of you or others feel strongly about it, I would like to keep it in its current form.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2068550089

From fyang at openjdk.org  Wed Apr 30 12:25:55 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 30 Apr 2025 12:25:55 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 30 Apr 2025 12:00:45 GMT, Robbin Ehn  wrote:

>> Hi, for you to consider.
>> 
>> These tests constantly fails in qemu-user.
>> Either the require host to be same arch explicit or implicit (sysroot).
>> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'" for SA tests.
>> 
>> From bug:
>>> qemu-user/rv64 sets uarch to "qemu" in /proc/cpuinfo (qemu-system do not do that).
>>> We add this uarch to CPU feature string.
>>> This means we can use jtreg 'require' with cpu string to filter out tests in qemu-user.
>> 
>> Relevant qemu code:
>> https://github.com/qemu/qemu/blob/170825d14d88a1ce7fae98d5a928480f2f329b22/linux-user/riscv/target_proc.h#L29
>> 
>> Relevant hotspot code:
>> https://github.com/openjdk/jdk/blob/fa0b18bfde38ee2ffbab33a9eaac547fe8aa3c7c/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L250
>> 
>> Tested that the require only filters out tests in qemu+riscv64.
>> 
>> Thanks!
>> 
>> /Robbin
>
> Robbin Ehn 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 branch 'master' into qemu-user-issues
>  - Merge branch 'master' into qemu-user-issues
>  - Revert
>  - Merge branch 'master' into qemu-user-issues
>  - Merge branch 'master' into qemu-user-issues
>  - more
>  - more
>  - native or very long

Thanks for finding these tests!

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24229#pullrequestreview-2806869108

From fyang at openjdk.org  Wed Apr 30 12:25:56 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 30 Apr 2025 12:25:56 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v3]
In-Reply-To: 
References: 
 <5sujqD7L_cmLUyDwYb4PhgOlEeiFwlkAV7RJoVMFTrM=.223437cd-bbb2-4ef3-a6fe-b13ce402e14b@github.com>
 
Message-ID: <0WJqqpLhGRgq64qQ21_NsZG8JAKTqllk5d8Zevg9hBs=.347c68b1-8284-4095-b6e5-010e47bce796@github.com>

On Wed, 30 Apr 2025 11:57:32 GMT, Robbin Ehn  wrote:

> I don't see any alternatives - if this approach is not liked, any suggestions?

The changes seems fine to me. It's just a pity that this would only work for riscv for now.
I guess we don't have a better choice given current status of qemu-user and the setting of jvm cpu string on different CPU platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2841798807

From rgiulietti at openjdk.org  Wed Apr 30 12:28:53 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 30 Apr 2025 12:28:53 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v48]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 20:33:29 GMT, fabioromano1  wrote:

>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplified the formula for detecting overflows

src/java.base/share/classes/java/math/BigInteger.java line 2737:

> 2735:         }
> 2736: 
> 2737:         return pow;

Is there a reason this cannot simply be the traditional "repeated square" method?
Why this complexity?

Suggestion:

        if (x == 1L)
            return 1L;

        if (x == 2L)
            return 1L << n;

        /*
         * The method assumption means that n <= 40 here.
         * Thus, the loop body executes at most 5 times.
         */ 
        long pow = 1;
        for (; n > 1; x *= x, n >>>= 1) {
            if ((n & 0b1) != 0) {
                pow *= x;
            }
        }
        return pow * x;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2068549452

From eirbjo at gmail.com  Wed Apr 30 12:41:28 2025
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Wed, 30 Apr 2025 14:41:28 +0200
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v2]
In-Reply-To: <9UXafhOZm046n5DgB9tyTu3Yw8U5w8sT5x9QCHpQsvI=.b0cc3d0b-bdb0-4d55-bbb9-3f80992423ae@github.com>
References: 
 
 <1aDEYvZqhjpU8GKqVGAZXqqL9wSY711AF_sfCmhUD68=.b98c6bf3-5b78-49a1-b934-93b135395a15@github.com>
 
 <5SCAZb6f9f9ZAPpVfUMOfBdctwfczvQ3effqbDX73cg=.7bd08fb9-a723-4cde-8f6c-ee2f4ea61ef6@github.com>
 
 <9UXafhOZm046n5DgB9tyTu3Yw8U5w8sT5x9QCHpQsvI=.b0cc3d0b-bdb0-4d55-bbb9-3f80992423ae@github.com>
Message-ID: 

ons. 30. apr. 2025 kl. 14:13 skrev Jaikiran Pai :

>
> Hello Eirik,
>
> > Before this change, two ZipFile instances opened using different
> (non-UTF-8) charsets would have equal keys, and thus be backed by the same
> Source and ZipCoder instance, whichever ZipFile constructed first would
> "win".
> > This seems like a separate bug, independent of the concurrency concerns
> described JDK-8347712.
> > For the benefit of future maintainers, I think this independent bug
> should be described in a separate JBS issue.
>
> That's right - when fixing 8347712 I saw this issue with `Key` class and
> addressed it in this PR. You have a good point that having a JBS issue
> specifically for this will be useful. I have now created
> https://bugs.openjdk.org/browse/JDK-8355975 and linked that issue in this
> current PR. What helped was your test case example that uses `ISO-8859-15`
> and `ISO-8859-1` charsets to trigger this issue. I wasn't aware of that
> difference between `ISO-8859-15` and `ISO-8859-1` charsets. Thank you, I've
> now added that test in this PR.


Thanks Jaikiran for addressing this bad other comments. I?m limited to the
mobile UI of GitHub right now, but everything looks good. Thanks for adding
the test ?

Eirik.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From alanb at openjdk.org  Wed Apr 30 12:50:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Apr 2025 12:50:48 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 07:54:23 GMT, Andrew Haley  wrote:

>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a null argument.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Since when?

@theRealAph Can you include the update to javax/security/auth/Subject.java as part of this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2841867570

From mcimadamore at openjdk.org  Wed Apr 30 12:53:50 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 30 Apr 2025 12:53:50 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 12:33:59 GMT, Jan Lahoda  wrote:

>> This is a patch to finalize the module imports feature. Please see:
>> https://bugs.openjdk.org/browse/JDK-8344700
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23801#pullrequestreview-2806949884

From mbaesken at openjdk.org  Wed Apr 30 13:10:32 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 30 Apr 2025 13:10:32 GMT
Subject: RFR: 8355979: ATTRIBUTE_NO_UBSAN needs to be extended to handle float
 divisions by zero on AIX
Message-ID: 

Seems the currently used ATTRIBUTE_NO_UBSAN does not handle the exclusion of float divisions by zero.
At least this is the case on AIX.

(seen in the jtreg test java/lang/Math/PowTests.java )

-------------

Commit messages:
 - JDK-8355979

Changes: https://git.openjdk.org/jdk/pull/24963/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24963&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355979
  Stats: 12 lines in 2 files changed: 6 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24963.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24963/head:pull/24963

PR: https://git.openjdk.org/jdk/pull/24963

From rriggs at openjdk.org  Wed Apr 30 13:13:30 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 30 Apr 2025 13:13:30 GMT
Subject: RFR: 8351000: StringBuilder getChar and putChar robustness [v2]
In-Reply-To: 
References: 
Message-ID: <9f4lA3Tae1Dz4COYa7Wgfa6OBj69ijQ2NJ1kSb9IF0I=.bc9d3029-d9f1-4d4a-aca3-44c1d0030131@github.com>

> Improve StringBuilder getChar and putChar robustness with racy updates to StringBuilder. 
> Test racing threads with append, insert, and reading characters.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Test cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24951/files
  - new: https://git.openjdk.org/jdk/pull/24951/files/0feabe83..e2b842cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24951&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24951&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24951.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24951/head:pull/24951

PR: https://git.openjdk.org/jdk/pull/24951

From liach at openjdk.org  Wed Apr 30 13:19:45 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 13:19:45 GMT
Subject: RFR: 8351000: StringBuilder getChar and putChar robustness [v2]
In-Reply-To: <9f4lA3Tae1Dz4COYa7Wgfa6OBj69ijQ2NJ1kSb9IF0I=.bc9d3029-d9f1-4d4a-aca3-44c1d0030131@github.com>
References: 
 <9f4lA3Tae1Dz4COYa7Wgfa6OBj69ijQ2NJ1kSb9IF0I=.bc9d3029-d9f1-4d4a-aca3-44c1d0030131@github.com>
Message-ID: <0YgMTm3WL89iMooPtAO_g2BdRBFq_T7RKRE7N-STjVc=.5b44442b-0591-48df-bd07-1ba4840f8ad8@github.com>

On Wed, 30 Apr 2025 13:13:30 GMT, Roger Riggs  wrote:

>> Improve StringBuilder getChar and putChar robustness with racy updates to StringBuilder. 
>> Test racing threads with append, insert, and reading characters.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test cleanup

Good cleanup, thanks @turbanoff!

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24951#pullrequestreview-2807026031

From swen at openjdk.org  Wed Apr 30 13:23:47 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 30 Apr 2025 13:23:47 GMT
Subject: RFR: 8351000: StringBuilder getChar and putChar robustness [v2]
In-Reply-To: <9f4lA3Tae1Dz4COYa7Wgfa6OBj69ijQ2NJ1kSb9IF0I=.bc9d3029-d9f1-4d4a-aca3-44c1d0030131@github.com>
References: 
 <9f4lA3Tae1Dz4COYa7Wgfa6OBj69ijQ2NJ1kSb9IF0I=.bc9d3029-d9f1-4d4a-aca3-44c1d0030131@github.com>
Message-ID: 

On Wed, 30 Apr 2025 13:13:30 GMT, Roger Riggs  wrote:

>> Improve StringBuilder getChar and putChar robustness with racy updates to StringBuilder. 
>> Test racing threads with append, insert, and reading characters.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test cleanup

test/jdk/java/lang/StringBuilder/RacingSBThreads.java line 64:

> 62: 
> 63:     // Create a String with a repeated character
> 64:     private static String initString(char c, int len) {

It may be easier to understand if initString is renamed to repeat

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24951#discussion_r2068653589

From jkern at openjdk.org  Wed Apr 30 13:25:54 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 30 Apr 2025 13:25:54 GMT
Subject: RFR: 8355979: ATTRIBUTE_NO_UBSAN needs to be extended to handle
 float divisions by zero on AIX
In-Reply-To: 
References: 
Message-ID: 

On Wed, 30 Apr 2025 13:04:18 GMT, Matthias Baesken  wrote:

> Seems the currently used ATTRIBUTE_NO_UBSAN does not handle the exclusion of float divisions by zero.
> At least this is the case on AIX.
> 
> (seen in the jtreg test java/lang/Math/PowTests.java )

LGTM

-------------

Marked as reviewed by jkern (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24963#pullrequestreview-2807043139

From jvernee at openjdk.org  Wed Apr 30 13:39:48 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 30 Apr 2025 13:39:48 GMT
Subject: RFR: 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe
In-Reply-To: 
References: 
Message-ID: 

On Mon, 24 Feb 2025 23:47:02 GMT, Chen Liang  wrote:

> Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set.

The changes look okay. I agree with Jaikiran that adding a stress test for this would be good.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23757#pullrequestreview-2807091979

From alanb at openjdk.org  Wed Apr 30 13:45:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Apr 2025 13:45:49 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 30 Apr 2025 00:56:19 GMT, Ioi Lam  wrote:

>> This PR contains 2 parts
>> 
>> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
>> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.
>> 
>> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):
>> 
>> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
>> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 
>> 
>> `ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:
>> 
>> - If an entry has not yet been collected, we make sure it will never be collected.
>> - If an entry has been collected, we remove it from the table
>> 
>> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.
>> 
>> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.
>> 
>> In the future, we may relax the implementation to allow for other use cases.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renamed the internal field ReferenceQueue.NULL to NULL_QUEUE to avoid failing hotspot/jtreg/sources/TestNoNULL.java

src/java.base/share/classes/java/lang/ref/Reference.java line 313:

> 311:     }
> 312: 
> 313:     private static void runtimeSetup() {

I don't know if you are planning an annotation or something to mark these "runtimeSetup" methods but each one will minimally need a comment so that it's clear to anyone touching this code that it may be called by the VM when loading the AOT cache.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2068697659

From lancea at openjdk.org  Wed Apr 30 13:48:49 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 30 Apr 2025 13:48:49 GMT
Subject: RFR: 8351000: StringBuilder getChar and putChar robustness [v2]
In-Reply-To: <9f4lA3Tae1Dz4COYa7Wgfa6OBj69ijQ2NJ1kSb9IF0I=.bc9d3029-d9f1-4d4a-aca3-44c1d0030131@github.com>
References: 
 <9f4lA3Tae1Dz4COYa7Wgfa6OBj69ijQ2NJ1kSb9IF0I=.bc9d3029-d9f1-4d4a-aca3-44c1d0030131@github.com>
Message-ID: 

On Wed, 30 Apr 2025 13:13:30 GMT, Roger Riggs  wrote:

>> Improve StringBuilder getChar and putChar robustness with racy updates to StringBuilder. 
>> Test racing threads with append, insert, and reading characters.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test cleanup

Test cleanup looks fine Roger

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24951#pullrequestreview-2807131101

From lancea at openjdk.org  Wed Apr 30 13:49:59 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 30 Apr 2025 13:49:59 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v7]
In-Reply-To: <7-hlRi4K3O2f8GbvfOy7Znvvgwyr8pP9BRaIIn4yikM=.1abe74c0-ac9c-447a-956e-49c2d5a93c39@github.com>
References: 
 <7-hlRi4K3O2f8GbvfOy7Znvvgwyr8pP9BRaIIn4yikM=.1abe74c0-ac9c-447a-956e-49c2d5a93c39@github.com>
Message-ID: <58DGueeNtyr2dvz3mpHtkN-0IwTBob7FTE7qSxf4-Tw=.eaf788a7-ed25-4551-95e9-7bda041a366b@github.com>

On Wed, 30 Apr 2025 12:02:25 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.
>> 
>> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.
>> 
>> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.
>> 
>> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta...
>
> 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 21 additional commits since the last revision:
> 
>  - Eirik's review about code comments
>  - fix comment typo
>  - merge latest from master branch
>  - 8355975: introduce a test for 8355975
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - improve code comment for ZipFile.zipCoder
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/c0f4b933...9a29b960

Hi Jai,

A few minor comments on the last set of changes.  Going to make another pass through the previous changes.

test/jdk/java/util/zip/ZipFile/ZipFileCharsetTest.java line 59:

> 57:      * A ZipFile can be constructed by passing a Charset which will be used to
> 58:      * decode the entry names (and comment) in a ZIP file.
> 59:      * The test here verifies that when multiple ZipFile instances are

Minor nit

'The test here verifies' -> "The test verifies'

test/jdk/java/util/zip/ZipFile/ZipFileCharsetTest.java line 68:

> 66:         // ISO-8859-15 is not a standard charset in Java. We skip this test
> 67:         // when it is unavailable
> 68:         assumeTrue(Charset.availableCharsets().containsKey(ISO_8859_15_NAME),

I would suggest throwing SkippedException otherwise junit throws org.opentest4j.TestAbortedException  If I understand correctly

-------------

PR Review: https://git.openjdk.org/jdk/pull/23986#pullrequestreview-2807011149
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2068641256
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2068637944

From jvernee at openjdk.org  Wed Apr 30 13:52:49 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 30 Apr 2025 13:52:49 GMT
Subject: RFR: 8297727: Forcing LF interpretation lead to StackOverflowError
 in reflection code
In-Reply-To: <92SXp91ulmlGXdPzA4fm7FwYDNiSE-_dEVzmJIf_Ahc=.4f3667c2-59df-4cca-b66f-8036ba871e57@github.com>
References: <92SXp91ulmlGXdPzA4fm7FwYDNiSE-_dEVzmJIf_Ahc=.4f3667c2-59df-4cca-b66f-8036ba871e57@github.com>
Message-ID: <0q6FYbt8XUKkKh5uSTJ910955kWwm_EGydo39dq7jLA=.b65bb864-93c5-42b8-beec-2bcbb3f75ab2@github.com>

On Wed, 23 Apr 2025 22:39:40 GMT, Chen Liang  wrote:

> When LambdaForms are interpreted, so are field lambda forms. When this happens, we may get into an infinite recursion due to field lambda forms using `MethodHandleStatics.UNSAFE` via field lambda form.
> 
> I think the best solution here is to always eagerly compile field DMH forms - we already do so for all method forms, and there is a finite number of field forms, mostly pregenerated. The reference with cast form is erroneously missed, and it is actually the culprit of this issue. Will pregenerate that in another patch.

Marked as reviewed by jvernee (Reviewer).

src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java line 217:

> 215:         }
> 216:         LambdaForm lform = preparedLambdaForm(mtype, which);
> 217:         maybeCompile(lform, m);

Ok, looks like this can be dropped because we always call `compileToBytecode` in `makePreparedLambdaForm`?

-------------

PR Review: https://git.openjdk.org/jdk/pull/24835#pullrequestreview-2807133715
PR Review Comment: https://git.openjdk.org/jdk/pull/24835#discussion_r2068704507

From duke at openjdk.org  Wed Apr 30 13:52:50 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 30 Apr 2025 13:52:50 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v48]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 30 Apr 2025 12:20:39 GMT, Raffaello Giulietti  wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplified the formula for detecting overflows
>
> src/java.base/share/classes/java/math/BigInteger.java line 2737:
> 
>> 2735:         }
>> 2736: 
>> 2737:         return pow;
> 
> Is there a reason this cannot simply be the traditional "repeated square" method?
> Why this complexity?
> 
> Suggestion:
> 
>         if (x == 1L)
>             return 1L;
> 
>         if (x == 2L)
>             return 1L << n;
> 
>         /*
>          * The method assumption means that n <= 40 here.
>          * Thus, the loop body executes at most 5 times.
>          */ 
>         long pow = 1;
>         for (; n > 1; x *= x, n >>>= 1) {
>             if ((n & 0b1) != 0) {
>                 pow *= x;
>             }
>         }
>         return pow * x;

@rgiulietti Probably the `powerCache` array is needless because the number of iterations is very low. Perhaps using `Math.pow(int, int)` could be a faster way to get the powers, since it reduces the number of iterations further and it has constant time, although even the traditional "repeated square" method has constant time...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2068708270

From rriggs at openjdk.org  Wed Apr 30 13:53:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 30 Apr 2025 13:53:55 GMT
Subject: Integrated: 8351000: StringBuilder getChar and putChar robustness
In-Reply-To: 
References: 
Message-ID: 

On Tue, 29 Apr 2025 14:10:30 GMT, Roger Riggs  wrote:

> Improve StringBuilder getChar and putChar robustness with racy updates to StringBuilder. 
> Test racing threads with append, insert, and reading characters.

This pull request has now been integrated.

Changeset: 4c695fa8
Author:    Roger Riggs 
URL:       https://git.openjdk.org/jdk/commit/4c695fa8a459adcdb8cdfe9e90783007c65fb90e
Stats:     313 lines in 2 files changed: 308 ins; 1 del; 4 mod

8351000: StringBuilder getChar and putChar robustness

Reviewed-by: liach, lancea, rgiulietti, pminborg

-------------

PR: https://git.openjdk.org/jdk/pull/24951

From duke at openjdk.org  Wed Apr 30 14:02:51 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 30 Apr 2025 14:02:51 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v48]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 30 Apr 2025 12:20:39 GMT, Raffaello Giulietti  wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplified the formula for detecting overflows
>
> src/java.base/share/classes/java/math/BigInteger.java line 2737:
> 
>> 2735:         }
>> 2736: 
>> 2737:         return pow;
> 
> Is there a reason this cannot simply be the traditional "repeated square" method?
> Why this complexity?
> 
> Suggestion:
> 
>         if (x == 1L)
>             return 1L;
> 
>         if (x == 2L)
>             return 1L << n;
> 
>         /*
>          * The method assumption means that n <= 40 here.
>          * Thus, the loop body executes at most 5 times.
>          */ 
>         long pow = 1;
>         for (; n > 1; x *= x, n >>>= 1) {
>             if ((n & 0b1) != 0) {
>                 pow *= x;
>             }
>         }
>         return pow * x;

@rgiulietti More than else, since `Math.pow(double, double)` has a lot of optimizations, I expect it to be faster than the simple "repeated square" method...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2068730720

From liach at openjdk.org  Wed Apr 30 14:02:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 14:02:52 GMT
Subject: RFR: 8297727: Forcing LF interpretation lead to StackOverflowError
 in reflection code
In-Reply-To: <0q6FYbt8XUKkKh5uSTJ910955kWwm_EGydo39dq7jLA=.b65bb864-93c5-42b8-beec-2bcbb3f75ab2@github.com>
References: <92SXp91ulmlGXdPzA4fm7FwYDNiSE-_dEVzmJIf_Ahc=.4f3667c2-59df-4cca-b66f-8036ba871e57@github.com>
 <0q6FYbt8XUKkKh5uSTJ910955kWwm_EGydo39dq7jLA=.b65bb864-93c5-42b8-beec-2bcbb3f75ab2@github.com>
Message-ID: 

On Wed, 30 Apr 2025 13:46:57 GMT, Jorn Vernee  wrote:

>> When LambdaForms are interpreted, so are field lambda forms. When this happens, we may get into an infinite recursion due to field lambda forms using `MethodHandleStatics.UNSAFE` via field lambda form.
>> 
>> I think the best solution here is to always eagerly compile field DMH forms - we already do so for all method forms, and there is a finite number of field forms, mostly pregenerated. The reference with cast form is erroneously missed, and it is actually the culprit of this issue. Will pregenerate that in another patch.
>
> src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java line 217:
> 
>> 215:         }
>> 216:         LambdaForm lform = preparedLambdaForm(mtype, which);
>> 217:         maybeCompile(lform, m);
> 
> Ok, looks like this can be dropped because we always call `compileToBytecode` in `makePreparedLambdaForm`?

Indeed, maybeCompile is actually weaker as it does not replace interpreter vmentry

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24835#discussion_r2068730862

From jpai at openjdk.org  Wed Apr 30 14:14:28 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Apr 2025 14:14:28 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v8]
In-Reply-To: 
References: 
Message-ID: 

> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.
> 
> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.
> 
> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.
> 
> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.
> 
> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.
> 
> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now maintained in the `ZipFile`,...

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Lance's review - update code comment in the test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23986/files
  - new: https://git.openjdk.org/jdk/pull/23986/files/9a29b960..71cb9781

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23986&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23986&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23986.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23986/head:pull/23986

PR: https://git.openjdk.org/jdk/pull/23986

From jpai at openjdk.org  Wed Apr 30 14:14:32 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Apr 2025 14:14:32 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v7]
In-Reply-To: <58DGueeNtyr2dvz3mpHtkN-0IwTBob7FTE7qSxf4-Tw=.eaf788a7-ed25-4551-95e9-7bda041a366b@github.com>
References: 
 <7-hlRi4K3O2f8GbvfOy7Znvvgwyr8pP9BRaIIn4yikM=.1abe74c0-ac9c-447a-956e-49c2d5a93c39@github.com>
 <58DGueeNtyr2dvz3mpHtkN-0IwTBob7FTE7qSxf4-Tw=.eaf788a7-ed25-4551-95e9-7bda041a366b@github.com>
Message-ID: 

On Wed, 30 Apr 2025 13:14:28 GMT, Lance Andersen  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 21 additional commits since the last revision:
>> 
>>  - Eirik's review about code comments
>>  - fix comment typo
>>  - merge latest from master branch
>>  - 8355975: introduce a test for 8355975
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - improve code comment for ZipFile.zipCoder
>>  - ... and 11 more: https://git.openjdk.org/jdk/compare/dad821f7...9a29b960
>
> test/jdk/java/util/zip/ZipFile/ZipFileCharsetTest.java line 59:
> 
>> 57:      * A ZipFile can be constructed by passing a Charset which will be used to
>> 58:      * decode the entry names (and comment) in a ZIP file.
>> 59:      * The test here verifies that when multiple ZipFile instances are
> 
> Minor nit
> 
> 'The test here verifies' -> "The test verifies'

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2068751644

From rriggs at openjdk.org  Wed Apr 30 14:21:17 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 30 Apr 2025 14:21:17 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder
Message-ID: 

Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
Support methods are static, designed to pass all values as arguments and return a value.

The value byte array is reallocated under 3 conditions:
- Increasing the capacity with the same encoder
- Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
- Inflation with the same capacity

Added StressSBTest to exercise public instance methods of StringBuilder.

-------------

Commit messages:
 - 8351443: Refactor AbstractStringBuilder to maintain consistency between

Changes: https://git.openjdk.org/jdk/pull/24967/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24967&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351443
  Stats: 885 lines in 7 files changed: 655 ins; 55 del; 175 mod
  Patch: https://git.openjdk.org/jdk/pull/24967.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24967/head:pull/24967

PR: https://git.openjdk.org/jdk/pull/24967

From jvernee at openjdk.org  Wed Apr 30 14:21:49 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 30 Apr 2025 14:21:49 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 30 Apr 2025 10:55:41 GMT, Per Minborg  wrote:

>> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
>> 
>> Re-allocated segments are not zeroed between allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test coverage and add convenience methods

It looks like you've made some other changes since the first patch. It would be useful if you could summarize those changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2842146770

From jpai at openjdk.org  Wed Apr 30 14:22:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Apr 2025 14:22:56 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v7]
In-Reply-To: <58DGueeNtyr2dvz3mpHtkN-0IwTBob7FTE7qSxf4-Tw=.eaf788a7-ed25-4551-95e9-7bda041a366b@github.com>
References: 
 <7-hlRi4K3O2f8GbvfOy7Znvvgwyr8pP9BRaIIn4yikM=.1abe74c0-ac9c-447a-956e-49c2d5a93c39@github.com>
 <58DGueeNtyr2dvz3mpHtkN-0IwTBob7FTE7qSxf4-Tw=.eaf788a7-ed25-4551-95e9-7bda041a366b@github.com>
Message-ID: 

On Wed, 30 Apr 2025 13:12:37 GMT, Lance Andersen  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 21 additional commits since the last revision:
>> 
>>  - Eirik's review about code comments
>>  - fix comment typo
>>  - merge latest from master branch
>>  - 8355975: introduce a test for 8355975
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - improve code comment for ZipFile.zipCoder
>>  - ... and 11 more: https://git.openjdk.org/jdk/compare/9d9004bf...9a29b960
>
> test/jdk/java/util/zip/ZipFile/ZipFileCharsetTest.java line 68:
> 
>> 66:         // ISO-8859-15 is not a standard charset in Java. We skip this test
>> 67:         // when it is unavailable
>> 68:         assumeTrue(Charset.availableCharsets().containsKey(ISO_8859_15_NAME),
> 
> I would suggest throwing SkippedException otherwise junit throws org.opentest4j.TestAbortedException  If I understand correctly

Hello Lance, I was under the impression that the jtreg framework would mark an aborted junit test as skipped. Now that you mentioned this, I checked locally and in its current form, jtreg reports this test as:


STARTED    ZipFileCharsetTest::testCachedZipFileSource 'testCachedZipFileSource()'
org.opentest4j.TestAbortedException: Assumption failed: skipping test since ISO-8859-15 charset isn't available
ABORTED    ZipFileCharsetTest::testCachedZipFileSource 'testCachedZipFileSource()' [37ms]

[ JUnit Containers: found 4, started 4, succeeded 4, failed 0, aborted 0, skipped 0]
[ JUnit Tests: found 1, started 1, succeeded 0, failed 0, aborted 1, skipped 0]




So it's being classified by jtreg as aborted instead of skipped. 

I then took your suggestion to throw `jtreg.SkippedException`:


+import jtreg.SkippedException;
-import static org.junit.jupiter.api.Assumptions.assumeTrue;
 
+ * @library /test/lib
  * @run junit ZipFileCharsetTest
  */
 public class ZipFileCharsetTest {
 
         // ISO-8859-15 is not a standard charset in Java. We skip this test
         // when it is unavailable
-        assumeTrue(Charset.availableCharsets().containsKey(ISO_8859_15_NAME),
-                "skipping test since " + ISO_8859_15_NAME + " charset isn't available");
+        if (!Charset.availableCharsets().containsKey(ISO_8859_15_NAME)) {
+            throw new SkippedException("skipping test since " + ISO_8859_15_NAME
+                    + " charset isn't available");
+        }



That however makes jtreg mark this test as failed instead of skipped:


STARTED    ZipFileCharsetTest::testCachedZipFileSource 'testCachedZipFileSource()'
jtreg.SkippedException: skipping test since ISO-8859-15 charset isn't available
    at ZipFileCharsetTest.testCachedZipFileSource(ZipFileCharsetTest.java:70)
    at java.base/java.lang.reflect.Method.invoke(Method.java:565)
    at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
    at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
FAILED     ZipFileCharsetTest::testCachedZipFileSource 'testCachedZipFileSource()' [28ms]
JavaTest Message: JUnit Platform Failure(s): 1

[ JUnit Containers: found 4, started 4, succeeded 4, failed 0, aborted 0, skipped 0]
[ JUnit Tests: found 1, started 1, succeeded 0, failed 1, aborted 0, skipped 0]


So it looks like we have an issue here with jtreg when it runs a junit test and the test throws `jtreg.SkippedException`. There appears to be an open issue for that (although in context of testng) https://bugs.openjdk.org/browse/CODETOOLS-7902676.

Given this, I can't think of a different way to handle this situation. Would it be OK to continue using `assumeTrue(...)` for now?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2068769646

From rgiulietti at openjdk.org  Wed Apr 30 14:23:52 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 30 Apr 2025 14:23:52 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v48]
In-Reply-To: 
References: 
 
 
 
Message-ID: <6b2DYckAPV4mJFF4D8v5yALAl5QaUYRTmb6WR141Kvs=.d7a1bfd2-0b0b-42cb-813e-638f658bec51@github.com>

On Wed, 30 Apr 2025 14:00:10 GMT, fabioromano1  wrote:

>> src/java.base/share/classes/java/math/BigInteger.java line 2737:
>> 
>>> 2735:         }
>>> 2736: 
>>> 2737:         return pow;
>> 
>> Is there a reason this cannot simply be the traditional "repeated square" method?
>> Why this complexity?
>> 
>> Suggestion:
>> 
>>         if (x == 1L)
>>             return 1L;
>> 
>>         if (x == 2L)
>>             return 1L << n;
>> 
>>         /*
>>          * The method assumption means that n <= 40 here.
>>          * Thus, the loop body executes at most 5 times.
>>          */ 
>>         long pow = 1;
>>         for (; n > 1; x *= x, n >>>= 1) {
>>             if ((n & 0b1) != 0) {
>>                 pow *= x;
>>             }
>>         }
>>         return pow * x;
>
> @rgiulietti More than else, since `Math.pow(double, double)` has a lot of optimizations, I expect it to be faster than the simple "repeated square" method...

@fabioromano1 pow(double,double) is quite complex, regardless of whether it is implemented in software or hardware. In fact, it's one of the most complex math functions, one of the reasons being that it takes two arguments.
The implementation invoked in `StrictMath` is more than 200 lines long (including comments).

The "repeated square" slow-path executes ? 11 `long` multiplications.
Plus, we need to balance performance and readability.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24690#discussion_r2068770121

From kbarrett at openjdk.org  Wed Apr 30 14:24:49 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 30 Apr 2025 14:24:49 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 30 Apr 2025 00:56:19 GMT, Ioi Lam  wrote:

>> This PR contains 2 parts
>> 
>> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
>> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.
>> 
>> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):
>> 
>> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
>> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 
>> 
>> `ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:
>> 
>> - If an entry has not yet been collected, we make sure it will never be collected.
>> - If an entry has been collected, we remove it from the table
>> 
>> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.
>> 
>> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.
>> 
>> In the future, we may relax the implementation to allow for other use cases.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renamed the internal field ReferenceQueue.NULL to NULL_QUEUE to avoid failing hotspot/jtreg/sources/TestNoNULL.java

src/java.base/share/classes/jdk/internal/util/ReferencedKeyMap.java line 353:

> 351:         for (ReferenceKey key : map.keySet()) {
> 352:             Object referent = key.get();
> 353:             if (referent == null) {

Shouldn't this be `key.refersTo(null)`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2068761761

From pminborg at openjdk.org  Wed Apr 30 14:27:46 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Apr 2025 14:27:46 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder
In-Reply-To: 
References: 
Message-ID: 

On Wed, 30 Apr 2025 14:12:36 GMT, Roger Riggs  wrote:

> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
> Support methods are static, designed to pass all values as arguments and return a value.
> 
> The value byte array is reallocated under 3 conditions:
> - Increasing the capacity with the same encoder
> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
> - Inflation with the same capacity
> 
> Added StressSBTest to exercise public instance methods of StringBuilder.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 732:

> 730:         byte[] value = ensureCapacitySameCoder(this.value, coder, count + 4);
> 731:         if (isLatin1(coder)) {
> 732:             value[count++] = 'n';

Can we benefit from MergeStores if we use fixed `count` offsets and then bump up `count` by four after the stores?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2068778082

From liach at openjdk.org  Wed Apr 30 14:30:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 14:30:51 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder
In-Reply-To: 
References: 
Message-ID: <7FdxbG-wkqLX929z_N5IHzxNOavX-jBILZQATNmL1HQ=.084c0d72-52a8-411b-90d5-37e5179047f0@github.com>

On Wed, 30 Apr 2025 14:12:36 GMT, Roger Riggs  wrote:

> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
> Support methods are static, designed to pass all values as arguments and return a value.
> 
> The value byte array is reallocated under 3 conditions:
> - Increasing the capacity with the same encoder
> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
> - Inflation with the same capacity
> 
> Added StressSBTest to exercise public instance methods of StringBuilder.

src/java.base/share/classes/java/lang/StringLatin1.java line 58:

> 56: 
> 57:     public static byte coderFromChar(char cp) {
> 58:         return (byte)((0xff - cp) >>> Integer.SIZE - 1);

Suggestion:

        return (byte)((0xff - cp) >>> (Integer.SIZE - 1));

For clarity.

Or use `return (byte)((0xff - cp) >>> Character.SIZE);` as this bit is set in `0xFF - 0xFFFF`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2068778745

From liach at openjdk.org  Wed Apr 30 14:32:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 14:32:51 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v8]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 30 Apr 2025 14:16:27 GMT, Kim Barrett  wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Renamed the internal field ReferenceQueue.NULL to NULL_QUEUE to avoid failing hotspot/jtreg/sources/TestNoNULL.java
>
> src/java.base/share/classes/jdk/internal/util/ReferencedKeyMap.java line 353:
> 
>> 351:         for (ReferenceKey key : map.keySet()) {
>> 352:             Object referent = key.get();
>> 353:             if (referent == null) {
> 
> Shouldn't this be `key.refersTo(null)`?

It is immediately passed to `CDS.keepAlive`, two separate calls of `refersTo` and `get` may produce `null` on the second call, I presume.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2068786986

From dfuchs at openjdk.org  Wed Apr 30 14:47:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 30 Apr 2025 14:47:58 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v3]
In-Reply-To: 
References: 
 
Message-ID: <6rOiDIAFxUmXy6EAQtxDeTbep9DOF5MJIKgi4fGTnQI=.a29afc53-d854-4d0a-9135-b454146b5a3c@github.com>

On Wed, 30 Apr 2025 10:19:54 GMT, Daniel Fuchs  wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement 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 411 commits:
> 
>  - merge latest changes from master branch
>  - http3: jep review feedback: rename HttpRequest.HttpRequestOption into top-level HttpOption. Http3DiscoveryMode is now an inner class in HttpOption. Improved protocol selection documentation in HttpClient class-level apiNote. Add links from Builder.version methods.
>  - merge latest changes from master branch
>  - http3: add missing 
 separator to Http3DiscoveryMode.ALT_SVC API documentation
>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>  - http3: minor improvement to log message
>  - http3: Artur's review - remove commented out code from test
>  - http3: Artur's review - make methods package private
>  - ... and 401 more: https://git.openjdk.org/jdk/compare/c2485d5f...dfa26044

The PR has been updated with the following API doc changes:

 1. rename HttpRequestOption into HttpOption and make it
    a top level class.
    
 2. move Http3DiscoveryMode as an inner class in HttpOption

 3. improve the paragraph that talks about version selection
    in the HttpClient class-level impl note.

 4. improve the API documentation of the various Builder.version
    and HttpClient.version methods, adding links to the above
    paragraph

The CSR has not been updated yet - but an API documentation of the `java.net.http` module including these changes can be seen [here](https://cr.openjdk.org/~dfuchs/8291976/apidoc.02/api/java.net.http/module-summary.html)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24751#issuecomment-2842231948

From rriggs at openjdk.org  Wed Apr 30 14:52:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 30 Apr 2025 14:52:53 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 26 Mar 2025 17:31:47 GMT, Aleksey Shipilev  wrote:

>> When jspawnhelper fails for whatever reason, but more prominently due to [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the errors into stdout, but not to the relevant `IOException`. So, if the application is configured to only capture the exception logs (e.g. through `java.util.logging`), we will miss any output from `jspawnhelper`, and user would be left without a clue what have happened. We have seen customers spending weeks trying to figure out what went wrong.
>> 
>> It would be good to provide useful `IOException` when `jspawnhelper` fails. We already have a precedent with vmError [printing helpful suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) when VM fails, we can do a similar thing here. 
>> 
>> I am very open to bike-shedding about the actual message :)
>> 
>> Additional testing:
>>  - [x] Ad-hoc experiments with breaking jspawnhelper
>>  - [x] macos-aarch64-server-fastdebug, `java/lang/Process java/lang/ProcessBuilder`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pull message into a field

Please add the test number 8352533 to the @bug tag in Basic.java.
Otherwise looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24149#pullrequestreview-2807353675

From kbarrett at openjdk.org  Wed Apr 30 14:52:53 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 30 Apr 2025 14:52:53 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v8]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 30 Apr 2025 14:29:45 GMT, Chen Liang  wrote:

>> src/java.base/share/classes/jdk/internal/util/ReferencedKeyMap.java line 353:
>> 
>>> 351:         for (ReferenceKey key : map.keySet()) {
>>> 352:             Object referent = key.get();
>>> 353:             if (referent == null) {
>> 
>> Shouldn't this be `key.refersTo(null)`?
>
> It is immediately passed to `CDS.keepAlive`, two separate calls of `refersTo` and `get` may produce `null` on the second call, I presume.

Sorry, I missed that `referent` was used later if non-null.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2068838868

From rriggs at openjdk.org  Wed Apr 30 15:03:47 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 30 Apr 2025 15:03:47 GMT
Subject: RFR: 8355391: Use Long::hashCode in java.time
In-Reply-To: <35NfgP2ueIq0RkDomVTj7bLtM_R-qD7spwbhpIXNFZA=.99fab560-5969-4a75-9212-52626a3e5b62@github.com>
References: <35NfgP2ueIq0RkDomVTj7bLtM_R-qD7spwbhpIXNFZA=.99fab560-5969-4a75-9212-52626a3e5b62@github.com>
Message-ID: <6pFvkJpLIQVrGXgELkrnhDs3YgJ2-ufY6RaCA8kklkQ=.b565fc4c-994f-4329-994c-9ea11855e1bc@github.com>

On Wed, 30 Apr 2025 06:46:07 GMT, Volkan Yazici  wrote:

> Replace manual bitwise operations in `hashCode` implementations of `java.time` with `Long::hashCode`.

lgtm

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24959#pullrequestreview-2807397426

From pminborg at openjdk.org  Wed Apr 30 15:12:44 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Apr 2025 15:12:44 GMT
Subject: RFR: 8355391: Use Long::hashCode in java.time
In-Reply-To: <35NfgP2ueIq0RkDomVTj7bLtM_R-qD7spwbhpIXNFZA=.99fab560-5969-4a75-9212-52626a3e5b62@github.com>
References: <35NfgP2ueIq0RkDomVTj7bLtM_R-qD7spwbhpIXNFZA=.99fab560-5969-4a75-9212-52626a3e5b62@github.com>
Message-ID: 

On Wed, 30 Apr 2025 06:46:07 GMT, Volkan Yazici  wrote:

> Replace manual bitwise operations in `hashCode` implementations of `java.time` with `Long::hashCode`.

Looks fine! Thanks for this cleanup.

-------------

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24959#pullrequestreview-2807429588

From jpai at openjdk.org  Wed Apr 30 15:16:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Apr 2025 15:16:50 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v5]
In-Reply-To: <_zP64u9JLPKTCSjEHXNi8lz16v5bBc9NfwA0DzCSiuE=.724c4dbc-2352-4501-888f-2c7c163becca@github.com>
References: 
 
 <3uIPOhhrMCN0106ljoadfuUTEFEhCXQ4NdtKLpQ9fl8=.8f006567-142f-4359-8f65-fbec6284b4fe@github.com>
 <_zP64u9JLPKTCSjEHXNi8lz16v5bBc9NfwA0DzCSiuE=.724c4dbc-2352-4501-888f-2c7c163becca@github.com>
Message-ID: 

On Sun, 23 Mar 2025 08:55:33 GMT, Eirik Bj?rsn?s  wrote:

>> src/java.base/share/classes/java/util/zip/ZipFile.java line 384:
>> 
>>> 382:      * @param fallback the fallback ZipCoder to return if the entry doesn't require UTF-8
>>> 383:      */
>>> 384:     private static ZipCoder zipCoderFor(final byte[] cen, final int pos, final ZipCoder fallback) {
>> 
>> Have you tried putting an instance method on ZipFile instead as it has access to the zip coder. That would give you better abstraction and avoid needing to introduce "fallback" as that is confusing to see here.
>
> I agree with Alan that an instance method would provide better abstraction and avoid the somewhat clumsy "fallback" parameter introduced in my previous patch.
> 
> Here's a patch exploring the instance method:
> 
> 
> Index: src/java.base/share/classes/java/util/zip/ZipFile.java
> IDEA additional info:
> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
> <+>UTF-8
> ===================================================================
> diff --git a/src/java.base/share/classes/java/util/zip/ZipFile.java b/src/java.base/share/classes/java/util/zip/ZipFile.java
> --- a/src/java.base/share/classes/java/util/zip/ZipFile.java	(revision 83ac59fcd292c21bbff4e0ac243a6bf07b4b21dc)
> +++ b/src/java.base/share/classes/java/util/zip/ZipFile.java	(date 1742719028475)
> @@ -202,7 +202,7 @@
>          long t0 = System.nanoTime();
>  
>          this.zipCoder = ZipCoder.get(charset);
> -        this.res = new CleanableResource(this, zipCoder, file, mode);
> +        this.res = new CleanableResource(this, file, mode);
>  
>          PerfCounter.getZipFileOpenTime().addElapsedTimeFrom(t0);
>          PerfCounter.getZipFileCount().increment();
> @@ -292,7 +292,7 @@
>              // Look up the name and CEN header position of the entry.
>              // The resolved name may include a trailing slash.
>              // See Source::getEntryPos for details.
> -            EntryPos pos = res.zsrc.getEntryPos(name, true, zipCoder);
> +            EntryPos pos = res.zsrc.getEntryPos(name, true, this);
>              if (pos != null) {
>                  entry = getZipEntry(pos.name, pos.pos);
>              }
> @@ -332,7 +332,7 @@
>              if (Objects.equals(lastEntryName, entry.name)) {
>                  pos = lastEntryPos;
>              } else {
> -                EntryPos entryPos = zsrc.getEntryPos(entry.name, false, zipCoder);
> +                EntryPos entryPos = zsrc.getEntryPos(entry.name, false, this);
>                  if (entryPos != null) {
>                      pos = entryPos.pos;
>                  } else {
> @@ -374,26 +374,25 @@
>       * 

>       * A ZIP entry's name and comment fields may be encoded using UTF-8, in
>       * which case this method returns a UTF-8 capable {@code ZipCoder}. If the
> -     * entry doesn't require UTF-8, then this method returns the {@code fallback}
> -     * {@code ZipCoder}.
> +     * entry doesn't require UTF-8, then this method returns the
> +     * {@code ZipCoder} of the ZipFile.
>       *
>       * @param cen the CEN
>       * @param pos the ZIP entry's position in CEN
> -     * @param fallback the fallbac...

Hello Alan,

> Have you tried putting an instance method on ZipFile instead as it has access to the zip coder. That would give you better abstraction and avoid needing to introduce "fallback" as that is confusing to see here.

When I experimented with a fix for this issue, several weeks back, my initial version included a variant of what Eirik shows as a diff in his comment. I decided to shelve that in favour of what I currently have in my PR. The root of the issue is that we use the `ZipCoder` at two categorically different moments in the lifecycle of a `ZipFile` instance. Once when the `ZipFile` is still being constructed and once after the `ZipFile` instance is fully constructed.

In the constructor of the `ZipFile`, the code leads to the static `Source` class. A `ZipCoder` that's an instance member/method of `ZipFile` can be used but that would then mean that various code paths that spawn out of the `Source` class, while parsing the CEN, may end up operating on a `ZipFile` instance (while obtaining the `ZipCoder`) that isn't fully constructed yet. It would not be immediately obvious while reading or updating such code that the `ZipFile` instance may not yet have been fully constructed. So to reduce such usage I decided to pursue this alternate way where using these static methods would prevent such access to the `ZipFile` instance. It has it's own drawbacks like you note about the confusing method parameters. But I felt that this is better of the two approaches.

If you think we should consider the instance method approach, then let me know and I'll experiment more and see if any issues related to that can be minimized.

Maybe in some larger future work this entire code path can be redone in a manner that a ZipFile instance that isn't yet constructed, doesn't have such tight integration with the Source/cache class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2068893458

From pminborg at openjdk.org  Wed Apr 30 15:19:49 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Apr 2025 15:19:49 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 30 Apr 2025 10:55:41 GMT, Per Minborg  wrote:

>> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
>> 
>> Re-allocated segments are not zeroed between allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test coverage and add convenience methods

So, the recent changes relate mostly to improving test coverage and some fixes that were made as a result:
 * Reused tests from another PR with similar ambitions
 * Added convenience methods for being able to use a MemoryLayout directly
 * Added thread check in `Frame::allocate" preventing inadvertent sharing across threads
 * Broke out a test and marked it in a ProblemList (macosx malloc problem)
 * Adding overrides to the usual `Object` methods for `BufferStack`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2842344498

From jpai at openjdk.org  Wed Apr 30 15:19:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Apr 2025 15:19:51 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 30 Apr 2025 14:14:28 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.
>> 
>> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.
>> 
>> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.
>> 
>> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lance's review - update code comment in the test

I've now gone through all the review comments and have either addressed them or replied to them. So I don't have any additional changes in mind other than any additional review suggestions that may come up.

tier testing is currently in progress.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23986#issuecomment-2842344820

From pminborg at openjdk.org  Wed Apr 30 15:30:09 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Apr 2025 15:30:09 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v5]
In-Reply-To: 
References: 
Message-ID: 

> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
> 
> Re-allocated segments are not zeroed between allocations.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Use utility method rather than custom calculation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24829/files
  - new: https://git.openjdk.org/jdk/pull/24829/files/b1b84282..f9763285

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24829&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24829&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24829.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24829/head:pull/24829

PR: https://git.openjdk.org/jdk/pull/24829

From duke at openjdk.org  Wed Apr 30 15:33:37 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 30 Apr 2025 15:33:37 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v9]
In-Reply-To: 
References: 
Message-ID: <8SHcFyjNMhqcY0TDhwiLkCO-xottmOFa4nqeCDrglTc=.4122346e-5e83-4f40-abcf-415e33d214f0@github.com>

> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
> 
> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
> 
> To ensure quality...
> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  Applied changes proposed by Joe and Jaikiran: Using @inheritDoc to get JavaDocs without @since.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21730/files
  - new: https://git.openjdk.org/jdk/pull/21730/files/47fbca7e..99fcefbd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21730&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21730&range=07-08

  Stats: 6 lines in 2 files changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21730/head:pull/21730

PR: https://git.openjdk.org/jdk/pull/21730

From pminborg at openjdk.org  Wed Apr 30 15:33:52 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Apr 2025 15:33:52 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v6]
In-Reply-To: 
References: 
Message-ID: 

> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
> 
> Re-allocated segments are not zeroed between allocations.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Improve on comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24829/files
  - new: https://git.openjdk.org/jdk/pull/24829/files/f9763285..22c384f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24829&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24829&range=04-05

  Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24829.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24829/head:pull/24829

PR: https://git.openjdk.org/jdk/pull/24829

From duke at openjdk.org  Wed Apr 30 15:37:08 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 30 Apr 2025 15:37:08 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v9]
In-Reply-To: <8SHcFyjNMhqcY0TDhwiLkCO-xottmOFa4nqeCDrglTc=.4122346e-5e83-4f40-abcf-415e33d214f0@github.com>
References: 
 <8SHcFyjNMhqcY0TDhwiLkCO-xottmOFa4nqeCDrglTc=.4122346e-5e83-4f40-abcf-415e33d214f0@github.com>
Message-ID: 

On Wed, 30 Apr 2025 15:33:37 GMT, Markus KARG  wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes proposed by Joe and Jaikiran: Using @inheritDoc to get JavaDocs without @since.

src/java.base/share/classes/java/lang/String.java line 1739:

> 1737: 
> 1738:     /**
> 1739:      * {@inheritDoc CharSequence}

@jaikiran @jddarcy Sorry for bothering, but I do need your kind help here to get the code to exactly that shape that you want to have it. While `{@inheritDoc CharSequence}` does work very well for `StringBuilder` and `StringBuffer` (via `AbstractStringBuilder` to shorten code size), it simply doesn't have *any* effect when applied at `String`: `make docs` successfully finishes without warnings or errors, but `String.html` still contains just the link to `CharSequence` but *is missing* the copy of the JavaDoc main text. I simply do not see why. Any ideas? ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2068936532

From iklam at openjdk.org  Wed Apr 30 15:42:48 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 30 Apr 2025 15:42:48 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v8]
In-Reply-To: 
References: 
 
 
Message-ID: <6-qu1_BjQ41WzYq8LNM3jZTQ6jPsMP7kWVvX5wbtXk0=.8a563fda-8f4e-44e6-906a-fb829721de64@github.com>

On Wed, 30 Apr 2025 13:43:28 GMT, Alan Bateman  wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Renamed the internal field ReferenceQueue.NULL to NULL_QUEUE to avoid failing hotspot/jtreg/sources/TestNoNULL.java
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 313:
> 
>> 311:     }
>> 312: 
>> 313:     private static void runtimeSetup() {
> 
> I don't know if you are planning an annotation or something to mark these "runtimeSetup" methods but each one will minimally need a comment so that it's clear to anyone touching this code that it may be called by the VM when loading the AOT cache.

Yes, the plan is to use annotation to mark the `runtimeSetup` and `assemblySetup` methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2068947399

From bpb at openjdk.org  Wed Apr 30 15:46:46 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 30 Apr 2025 15:46:46 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value [v4]
In-Reply-To: 
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
 
 
 
 
 
Message-ID: 

On Wed, 30 Apr 2025 06:08:30 GMT, Alan Bateman  wrote:

>> Comment simplified in 4cee3c2.
>
> Okay, just a bit puzzled as to why it doesn't run on Linux. The VM uses setrlimit(RLIMIT_NOFILE) to set the limit to the hard limit (rlim_max). So is the issue here that the hard limit less than 2050 on some test systems?

It must have been that. I have not seen it fail on Linux in the CI nor locally with the `@requires` tag removed. I would be inclined to delete the tag and, if we see any failures later, reinstate it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24860#discussion_r2068955640

From liach at openjdk.org  Wed Apr 30 15:49:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 15:49:52 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v9]
In-Reply-To: 
References: 
 <8SHcFyjNMhqcY0TDhwiLkCO-xottmOFa4nqeCDrglTc=.4122346e-5e83-4f40-abcf-415e33d214f0@github.com>
 
Message-ID: 

On Wed, 30 Apr 2025 15:34:33 GMT, Markus KARG  wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Applied changes proposed by Joe and Jaikiran: Using @inheritDoc to get JavaDocs without @since.
>
> src/java.base/share/classes/java/lang/String.java line 1739:
> 
>> 1737: 
>> 1738:     /**
>> 1739:      * {@inheritDoc CharSequence}
> 
> @jaikiran @jddarcy Sorry for bothering, but I do need your kind help here to get the code to exactly that shape that you want to have it. While `{@inheritDoc CharSequence}` does work very well for `StringBuilder` and `StringBuffer` (via `AbstractStringBuilder` to shorten code size), it simply doesn't have *any* effect when applied at `String`: `make docs` successfully finishes without warnings or errors, but `String.html` still contains just the link to `CharSequence` but *is missing* the copy of the JavaDoc main text. I simply do not see why. Any ideas? ?

Could this be a Javadoc bug? What does a simple `{@inheritDoc}` do?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2068965855

From weijun at openjdk.org  Wed Apr 30 15:50:37 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 30 Apr 2025 15:50:37 GMT
Subject: RFR: 8347938: Switch to latest ML-KEM private key encoding
Message-ID: 

The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest IERTF drafts at: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-08 and https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-10. New security/system properties are introduced to determine which CHOICE a private key is encoded.

Both the encoding and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS #8 key, the expanded format is either calculated or copied from the input.

-------------

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/24969/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24969&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347938
  Stats: 2448 lines in 23 files changed: 1741 ins; 539 del; 168 mod
  Patch: https://git.openjdk.org/jdk/pull/24969.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24969/head:pull/24969

PR: https://git.openjdk.org/jdk/pull/24969

From rriggs at openjdk.org  Wed Apr 30 15:52:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 30 Apr 2025 15:52:52 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v5]
In-Reply-To: <4cfCydBqbJcxVuRmEf7W4ehFuz_MMf_zc4k5dxpQoCU=.cc4aaf74-5a6a-4213-857b-6b5f69fb63d1@github.com>
References: 
 <4cfCydBqbJcxVuRmEf7W4ehFuz_MMf_zc4k5dxpQoCU=.cc4aaf74-5a6a-4213-857b-6b5f69fb63d1@github.com>
Message-ID: 

On Wed, 23 Apr 2025 14:12:29 GMT, Chen Liang  wrote:

>> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list".
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java
>   
>   Co-authored-by: Raffaello Giulietti 

I would also point out that IntrinsicCandidate has some off-label uses, in which the method is not replaced by the runtime but is just recognized as distinguished methods and identified for some optimization case.  The most common cases are related to the string concatenation subsystem, for example, StringBuilder.append(String). This might be covered under jrose00's more general comment a week ago.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24777#issuecomment-2842453540

From pminborg at openjdk.org  Wed Apr 30 15:55:46 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Apr 2025 15:55:46 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 30 Apr 2025 15:33:52 GMT, Per Minborg  wrote:

>> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
>> 
>> Re-allocated segments are not zeroed between allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve on comments

Updated benchmarks:


Benchmark                            (ELEM_SIZE)  Mode  Cnt   Score   Error  Units
BufferStackBench.OfVirtual.buffer              8  avgt   15  12.653 ? 0.189  ns/op
BufferStackBench.OfVirtual.buffer             16  avgt   15  12.635 ? 0.228  ns/op
BufferStackBench.OfVirtual.buffer             32  avgt   15  12.562 ? 0.062  ns/op
BufferStackBench.OfVirtual.confined            8  avgt   15  22.649 ? 0.262  ns/op
BufferStackBench.OfVirtual.confined           16  avgt   15  23.507 ? 0.146  ns/op
BufferStackBench.OfVirtual.confined           32  avgt   15  25.426 ? 0.512  ns/op
BufferStackBench.buffer                        8  avgt   15   4.693 ? 0.037  ns/op
BufferStackBench.buffer                       16  avgt   15   4.715 ? 0.032  ns/op
BufferStackBench.buffer                       32  avgt   15   4.670 ? 0.038  ns/op
BufferStackBench.confined                      8  avgt   15  22.548 ? 0.022  ns/op
BufferStackBench.confined                     16  avgt   15  23.494 ? 0.092  ns/op
BufferStackBench.confined                     32  avgt   15  25.285 ? 0.076  ns/op


and


Benchmark                              Mode  Cnt   Score   Error  Units
CallOverheadByValue.OfVirtual.byPtr    avgt   15   4.095 ? 0.035  ns/op
CallOverheadByValue.OfVirtual.byValue  avgt   15  16.666 ? 0.208  ns/op
CallOverheadByValue.byPtr              avgt   15   4.132 ? 0.146  ns/op
CallOverheadByValue.byValue            avgt   15  11.835 ? 0.139  ns/op


Pases `tier1` testing on various platforms and JVM configurations

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24829#issuecomment-2842462592

From duke at openjdk.org  Wed Apr 30 15:59:05 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 30 Apr 2025 15:59:05 GMT
Subject: RFR: 8355719: Reduce memory consumption of BigInteger.pow() [v49]
In-Reply-To: 
References: 
Message-ID: 

> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in `pow()` is not concerned most on execution time, but rather in memory optimization, because the PR implementation does the "shift of the exponent" squaring the result rather than the base, so the base is not squared like in the current implementation, and this permits to save about half of the memory.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Simplify long power computing

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24690/files
  - new: https://git.openjdk.org/jdk/pull/24690/files/68959267..b8ca4fe4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=48
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24690&range=47-48

  Stats: 66 lines in 1 file changed: 4 ins; 58 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24690/head:pull/24690

PR: https://git.openjdk.org/jdk/pull/24690

From swen at openjdk.org  Wed Apr 30 16:01:47 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 30 Apr 2025 16:01:47 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder
In-Reply-To: 
References: 
Message-ID: 

On Wed, 30 Apr 2025 14:12:36 GMT, Roger Riggs  wrote:

> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
> Support methods are static, designed to pass all values as arguments and return a value.
> 
> The value byte array is reallocated under 3 conditions:
> - Increasing the capacity with the same encoder
> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
> - Inflation with the same capacity
> 
> Added StressSBTest to exercise public instance methods of StringBuilder.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1868:

> 1866: 
> 1867:     final boolean isLatin1() {
> 1868:         return COMPACT_STRINGS && coder == LATIN1;

Suggestion:

        return isLatin1(coder);

Can we reuse static isLatin1 like this?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24967#discussion_r2068986449

From pminborg at openjdk.org  Wed Apr 30 16:06:17 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 30 Apr 2025 16:06:17 GMT
Subject: Integrated: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 Mar 2025 18:11:23 GMT, Per Minborg  wrote:

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

This pull request has now been integrated.

Changeset: fbc4691b
Author:    Per Minborg 
URL:       https://git.openjdk.org/jdk/commit/fbc4691bfa11f31601fd89d05da63e689343e214
Stats:     4806 lines in 30 files changed: 4795 ins; 0 del; 11 mod

8351565: Implement JEP 502: Stable Values (Preview)

Co-authored-by: Maurizio Cimadamore 
Reviewed-by: vklang, jvernee, alanb, liach

-------------

PR: https://git.openjdk.org/jdk/pull/23972

From naoto at openjdk.org  Wed Apr 30 16:06:49 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 30 Apr 2025 16:06:49 GMT
Subject: RFR: 8355391: Use Long::hashCode in java.time
In-Reply-To: <35NfgP2ueIq0RkDomVTj7bLtM_R-qD7spwbhpIXNFZA=.99fab560-5969-4a75-9212-52626a3e5b62@github.com>
References: <35NfgP2ueIq0RkDomVTj7bLtM_R-qD7spwbhpIXNFZA=.99fab560-5969-4a75-9212-52626a3e5b62@github.com>
Message-ID: 

On Wed, 30 Apr 2025 06:46:07 GMT, Volkan Yazici  wrote:

> Replace manual bitwise operations in `hashCode` implementations of `java.time` with `Long::hashCode`.

LGTM. Thanks for the refactoring

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24959#pullrequestreview-2807607225

From duke at openjdk.org  Wed Apr 30 16:09:06 2025
From: duke at openjdk.org (Gautham Krishnan)
Date: Wed, 30 Apr 2025 16:09:06 GMT
Subject: Integrated: 8342886: Update MET timezone in TimeZoneNames files
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Apr 2025 09:57:38 GMT, Gautham Krishnan  wrote:

> MET timezone entry in TimeZoneNames.java and TimeZoneNames_*.java needs to be updated as MET is alias to Europe/Brussels as per 2024b tzdata changes.
> 
> Also Bug4848242.java needs to be removed as the test expects all euro locale time zones should have the same short names.

This pull request has now been integrated.

Changeset: 66122811
Author:    Gautham Krishnan <140151984+gauthamkrishnanibm at users.noreply.github.com>
Committer: Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/66122811aae02caaa0545a7b6dd1fdb06b186f00
Stats:     51 lines in 12 files changed: 3 ins; 22 del; 26 mod

8342886: Update MET timezone in TimeZoneNames files

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/24871

From liach at openjdk.org  Wed Apr 30 16:09:29 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 16:09:29 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v78]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 24 Apr 2025 10:37:59 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make public constuctor private

Congratulations! With the introduction of this as a preview feature, we can slowly improve it over time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2842498140

From shade at openjdk.org  Wed Apr 30 16:11:14 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Apr 2025 16:11:14 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v4]
In-Reply-To: 
References: 
Message-ID: <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com>

> When jspawnhelper fails for whatever reason, but more prominently due to [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the errors into stdout, but not to the relevant `IOException`. So, if the application is configured to only capture the exception logs (e.g. through `java.util.logging`), we will miss any output from `jspawnhelper`, and user would be left without a clue what have happened. We have seen customers spending weeks trying to figure out what went wrong.
> 
> It would be good to provide useful `IOException` when `jspawnhelper` fails. We already have a precedent with vmError [printing helpful suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) when VM fails, we can do a similar thing here. 
> 
> I am very open to bike-shedding about the actual message :)
> 
> Additional testing:
>  - [x] Ad-hoc experiments with breaking jspawnhelper
>  - [x] macos-aarch64-server-fastdebug, `java/lang/Process java/lang/ProcessBuilder`

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 six additional commits since the last revision:

 - Add bug ID
 - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
 - Pull message into a field
 - Test cases
 - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
 - Initial fix
   
   Good spawnhelper failure message
   
   Trying tests
   
   Print helper message on all IOExceptions
   
   Final

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24149/files
  - new: https://git.openjdk.org/jdk/pull/24149/files/f1b9a9af..74ddf9af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24149&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24149&range=02-03

  Stats: 317079 lines in 3027 files changed: 99805 ins; 205890 del; 11384 mod
  Patch: https://git.openjdk.org/jdk/pull/24149.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24149/head:pull/24149

PR: https://git.openjdk.org/jdk/pull/24149

From rriggs at openjdk.org  Wed Apr 30 16:11:14 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 30 Apr 2025 16:11:14 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v4]
In-Reply-To: <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com>
References: 
 <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com>
Message-ID: 

On Wed, 30 Apr 2025 16:07:56 GMT, Aleksey Shipilev  wrote:

>> When jspawnhelper fails for whatever reason, but more prominently due to [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the errors into stdout, but not to the relevant `IOException`. So, if the application is configured to only capture the exception logs (e.g. through `java.util.logging`), we will miss any output from `jspawnhelper`, and user would be left without a clue what have happened. We have seen customers spending weeks trying to figure out what went wrong.
>> 
>> It would be good to provide useful `IOException` when `jspawnhelper` fails. We already have a precedent with vmError [printing helpful suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) when VM fails, we can do a similar thing here. 
>> 
>> I am very open to bike-shedding about the actual message :)
>> 
>> Additional testing:
>>  - [x] Ad-hoc experiments with breaking jspawnhelper
>>  - [x] macos-aarch64-server-fastdebug, `java/lang/Process java/lang/ProcessBuilder`
>
> 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 six additional commits since the last revision:
> 
>  - Add bug ID
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Pull message into a field
>  - Test cases
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Initial fix
>    
>    Good spawnhelper failure message
>    
>    Trying tests
>    
>    Print helper message on all IOExceptions
>    
>    Final

Thanks for the bugid.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24149#pullrequestreview-2807614287

From shade at openjdk.org  Wed Apr 30 16:11:14 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Apr 2025 16:11:14 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <2_61hzKZNdizMxt2sWZ_GJnSP-4qKBn7zAFADrsq8TM=.ad4118cb-103a-476b-87b8-6770a0b31c9c@github.com>

On Wed, 30 Apr 2025 14:50:03 GMT, Roger Riggs  wrote:

> Please add the test number 8352533 to the @bug tag in Basic.java.

Thanks, added!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24149#issuecomment-2842494196

From swen at openjdk.org  Wed Apr 30 16:19:45 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 30 Apr 2025 16:19:45 GMT
Subject: RFR: 8351443: Improve robustness of StringBuilder
In-Reply-To: 
References: 
Message-ID: 

On Wed, 30 Apr 2025 14:12:36 GMT, Roger Riggs  wrote:

> Refactor AbstractStringBuilder to maintain consistency among count, coder, and value buffers while the buffer capacity is being expanded and/or inflated from Latin1 to UTF16 representations. 
> The refactoring pattern is to read and write AbstractStringBuilder fields once using locals for all intermediate values. 
> Support methods are static, designed to pass all values as arguments and return a value.
> 
> The value byte array is reallocated under 3 conditions:
> - Increasing the capacity with the same encoder
> - Increasing the capacity and inflation to change the coder from LATIN1 to UTF16
> - Inflation with the same capacity
> 
> Added StressSBTest to exercise public instance methods of StringBuilder.

StringLatin1 also provides the same putCharsAt method as StringUTF16, which may look better in appendNull and append(boolean), such as this


class AbstractStringBuilder {
    private AbstractStringBuilder appendNull() {
        byte coder = this.coder;
        int count = this.count;
        byte[] value = ensureCapacitySameCoder(this.value, coder, count + 4);
        if (isLatin1(coder)) {
            count = StringLatin1.putCharsAt(value, count, 'n', 'u', 'l', 'l');
        } else {
            count = StringUTF16.putCharsAt(value, count, 'n', 'u', 'l', 'l');
        }
        this.count = count;
        this.value = value;
        return this;
    }

    public AbstractStringBuilder append(boolean b) {
        byte coder = this.coder;
        int count = this.count;

        int newCount = count + (b ? 4 : 5);
        byte[] value = ensureCapacitySameCoder(this.value, coder, newCount);
        if (isLatin1(coder)) {
            if (b) {
                newCount = StringLatin1.putCharsAt(value, count, 't', 'r', 'u', 'e');
            } else {
                newCount = StringLatin1.putCharsAt(value, count, 'f', 'a', 'l', 's', 'e');
            }
        } else {
            if (b) {
                newCount = StringUTF16.putCharsAt(value, count, 't', 'r', 'u', 'e');
            } else {
                newCount = StringUTF16.putCharsAt(value, count, 'f', 'a', 'l', 's', 'e');
            }
        }
        this.value = value;
        this.count = newCount;
        return this;
    }
}


StringLatin1 also provides the same putCharsAt method as StringUTF16

final class StringLatin1 {
    public static int putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
        value[i    ] = (byte)(c1);
        value[i + 1] = (byte)(c2);
        value[i + 2] = (byte)(c3);
        value[i + 3] = (byte)(c4);
        return end;
    }

    public static int putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4, char c5) {
        int end = i + 5;
        value[i    ] = (byte)(c1);
        value[i + 1] = (byte)(c2);
        value[i + 2] = (byte)(c3);
        value[i + 3] = (byte)(c4);
        value[i + 4] = (byte)(c5);
        return end;
    }
}


StringUTF16 uses `+1 +2 +3 +4` to replace `++`

class StringUTF16 {
    public static int putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
        int end = i + 4;
        checkBoundsBeginEnd(i, end, value);
        putChar(value, i    , c1);
        putChar(value, i + 1, c2);
        putChar(value, i + 2, c3);
        putChar(value, i + 3, c4);
        assert(i + 4 == end);
        return end;
    }

    public static int putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4, char c5) {
        int end = i + 5;
        checkBoundsBeginEnd(i, end, value);
        putChar(value, i    , c1);
        putChar(value, i + 1, c2);
        putChar(value, i + 2, c3);
        putChar(value, i + 3, c4);
        putChar(value, i + 4, c5);
        assert(i + 5 == end);
        return end;
    }
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24967#issuecomment-2842531659

From vklang at openjdk.org  Wed Apr 30 16:32:50 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 30 Apr 2025 16:32:50 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v10]
In-Reply-To: <78kIw0fEwr28hUJiXvzVtzJiU45h92XUYbLOMJVx-qU=.41829434-dc66-4f8d-9eb4-b10948f3a2b2@github.com>
References: 
 <78kIw0fEwr28hUJiXvzVtzJiU45h92XUYbLOMJVx-qU=.41829434-dc66-4f8d-9eb4-b10948f3a2b2@github.com>
Message-ID: <9wy7VGRTEomoX5sxQJPnarVj_9lnjEoBfFoTYQpzdVE=.dd6391bc-32ce-45cb-8ce1-c7f62bc1d219@github.com>

On Tue, 29 Apr 2025 19:03:08 GMT, Chen Liang  wrote:

>> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
>> 
>> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
>> 
>> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
>> 
>> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.
>
> 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 17 additional commits since the last revision:
> 
>  - Rewrite impl to follow the new simplified spec
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - Try to simplify the model - use the finish of computeValue
>    
>  - Test updates - remove repetition, test case for no stale installation
>  - Fix incorrect promise removal when unnecessary and add regression test
>  - Cannot test for recursion eagerly - add test case
>  - More spec, eager exception, finish with existing, thanks John
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - docs
>  - Remove the throwing behavior due to shallow reentrancy
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/56c8a5ac...221d51e7

Hi @liach, I had a look, primarily on the changes rather than the tests, for this pass.

src/java.base/share/classes/java/lang/ClassValue.java line 95:

> 93:      * 
    
> 94:      * 
  • This association is already associated by another attempt. The
> 95:      * associated value is returned.
    • 

It's a bit unclear which association is referred to in the second sentence, I think that could be made clearer with something like:

Suggestion:

     * 
  • This association is already associated by another attempt, so that value is returned.
    • 

src/java.base/share/classes/java/lang/ClassValue.java line 124:

> 122:      * {@return the value associated to the given {@code Class}}
> 123:      * 
    
> 124:      * This method first performs a read-only access, and returns the associated

I'm not 100% sure on the "read-only" label here, as it does recompute-and-store if there is no current value.

src/java.base/share/classes/java/lang/ClassValue.java line 167:

> 165:     public void remove(Class type) {
> 166:         ClassValueMap map = getMap(type);
> 167:         map.removeAccess(this);

Should this really be "Access" and not "Association"?

src/java.base/share/classes/java/lang/ClassValue.java line 318:

> 316:     Version version() { return version; }
> 317:     void bumpVersion() { version = new Version<>(this); }
> 318:     static final class Version {

Since this is all final components, it might serve better as a record?

src/java.base/share/classes/java/lang/ClassValue.java line 377:

> 375:                 return new Entry<>(v2, value);
> 376:             }
> 377:             return this;

The following reads slightly better (to me):

Suggestion:

            return version.refersTo(v2) ? this : new Entry<>(v2, value);

test/jdk/java/lang/invoke/ClassValueTest.java line 179:

> 177: 
> 178:     private static final long COMPUTE_TIME_MILLIS = 100;
> 179:     private static final Duration TIMEOUT = Duration.of(2, ChronoUnit.SECONDS);

In order to reduce spurious failures here, I'd probably put this timeout a bit longer?let's say 5s.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24043#pullrequestreview-2806354549
PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2068235676
PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2069033640
PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2069037387
PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2069047258
PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2069052518
PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2069056808

From liach at openjdk.org  Wed Apr 30 17:02:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 17:02:55 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v10]
In-Reply-To: <9wy7VGRTEomoX5sxQJPnarVj_9lnjEoBfFoTYQpzdVE=.dd6391bc-32ce-45cb-8ce1-c7f62bc1d219@github.com>
References: 
 <78kIw0fEwr28hUJiXvzVtzJiU45h92XUYbLOMJVx-qU=.41829434-dc66-4f8d-9eb4-b10948f3a2b2@github.com>
 <9wy7VGRTEomoX5sxQJPnarVj_9lnjEoBfFoTYQpzdVE=.dd6391bc-32ce-45cb-8ce1-c7f62bc1d219@github.com>
Message-ID: 

On Wed, 30 Apr 2025 09:15:49 GMT, Viktor Klang  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 17 additional commits since the last revision:
>> 
>>  - Rewrite impl to follow the new simplified spec
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>>  - Try to simplify the model - use the finish of computeValue
>>    
>>  - Test updates - remove repetition, test case for no stale installation
>>  - Fix incorrect promise removal when unnecessary and add regression test
>>  - Cannot test for recursion eagerly - add test case
>>  - More spec, eager exception, finish with existing, thanks John
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>>  - docs
>>  - Remove the throwing behavior due to shallow reentrancy
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/153a25f7...221d51e7
>
> src/java.base/share/classes/java/lang/ClassValue.java line 95:
> 
>> 93:      * 
      
>> 94:      * 
    • This association is already associated by another attempt. The
>> 95:      * associated value is returned.
      • 
> 
> It's a bit unclear which association is referred to in the second sentence, I think that could be made clearer with something like:
> 
> Suggestion:
> 
>      * 
    • This association is already associated by another attempt, so that value is returned.
      • 

I think I will reword as:
"An association is already created by another attempt. The associated value is returned."

What do you think? An association is either present or absent for a coordinate. In addition, all other list entries are  "What happened. What happens next."

> src/java.base/share/classes/java/lang/ClassValue.java line 124:
> 
>> 122:      * {@return the value associated to the given {@code Class}}
>> 123:      * 
      
>> 124:      * This method first performs a read-only access, and returns the associated
> 
> I'm not 100% sure on the "read-only" label here, as it does recompute-and-store if there is no current value.

Yep, it needs a read-only access to know there is no current value...

> src/java.base/share/classes/java/lang/ClassValue.java line 167:
> 
>> 165:     public void remove(Class type) {
>> 166:         ClassValueMap map = getMap(type);
>> 167:         map.removeAccess(this);
> 
> Should this really be "Access" and not "Association"?

Oh, I named all methods on `ClassValueMap` to `access`. When a remove is done, it might remove a previous remove (no association) in addition to actual associations.

> src/java.base/share/classes/java/lang/ClassValue.java line 318:
> 
>> 316:     Version version() { return version; }
>> 317:     void bumpVersion() { version = new Version<>(this); }
>> 318:     static final class Version {
> 
> Since this is all final components, it might serve better as a record?

Note that this class has a significant identity. Does that make it still suitable for record conversion? I think we need a comment on its identity significance if we convert.

> test/jdk/java/lang/invoke/ClassValueTest.java line 179:
> 
>> 177: 
>> 178:     private static final long COMPUTE_TIME_MILLIS = 100;
>> 179:     private static final Duration TIMEOUT = Duration.of(2, ChronoUnit.SECONDS);
> 
> In order to reduce spurious failures here, I'd probably put this timeout a bit longer?let's say 5s.

Oh, the timeout is not to reduce failures - it mainly aims to prevent accidental infinite loops from stalling tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2069106581
PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2069108612
PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2069109848
PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2069113085
PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2069114518

From bpb at openjdk.org  Wed Apr 30 17:06:28 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 30 Apr 2025 17:06:28 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value [v6]
In-Reply-To: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
Message-ID: 

> Use the `@requires` tag instead of obtaining the operating system name from the `os.name` property and then exiting if the test is not run on that operating system.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8355444: Remove requires tag from ManyFiles

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24860/files
  - new: https://git.openjdk.org/jdk/pull/24860/files/4cee3c2b..260cb693

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24860&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24860&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24860/head:pull/24860

PR: https://git.openjdk.org/jdk/pull/24860

From bpb at openjdk.org  Wed Apr 30 17:06:28 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 30 Apr 2025 17:06:28 GMT
Subject: RFR: 8355444: [java.io] Use @requires tag instead of exiting based
 on "os.name" property value [v5]
In-Reply-To: 
References: <9-6zXOGfrsJgujLjZJsq7cZxRixMr6IwC_Y3JBz05-0=.c25c9510-7f4a-47e5-9043-472a49bb7dfc@github.com>
 
Message-ID: <6_f8t9QNb730K9z9G2Ngat9z_l5ZTyff_AmKqILQikQ=.fcd0a518-f13b-4e84-9bdc-de6b6b58091c@github.com>

On Tue, 29 Apr 2025 18:31:37 GMT, Brian Burkhalter  wrote:

>> Use the `@requires` tag instead of obtaining the operating system name from the `os.name` property and then exiting if the test is not run on that operating system.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8355444: Simplify comment about requires tag

I ran 30 repeats on each of the two Linux architectures in the CI with commit 260cb69 included and did not see any failures.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24860#issuecomment-2842662480

From duke at openjdk.org  Wed Apr 30 17:30:53 2025
From: duke at openjdk.org (#NotTheOne)
Date: Wed, 30 Apr 2025 17:30:53 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v4]
In-Reply-To: <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com>
References: 
 <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com>
Message-ID: <3HrW31ABkvyoyxTus3NhukO6iCjjFmhCY5PgUFPVGQA=.5849db27-966a-4dbb-864a-29c19c89a255@github.com>

On Wed, 30 Apr 2025 16:11:14 GMT, Aleksey Shipilev  wrote:

>> When jspawnhelper fails for whatever reason, but more prominently due to [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the errors into stdout, but not to the relevant `IOException`. So, if the application is configured to only capture the exception logs (e.g. through `java.util.logging`), we will miss any output from `jspawnhelper`, and user would be left without a clue what have happened. We have seen customers spending weeks trying to figure out what went wrong.
>> 
>> It would be good to provide useful `IOException` when `jspawnhelper` fails. We already have a precedent with vmError [printing helpful suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) when VM fails, we can do a similar thing here. 
>> 
>> I am very open to bike-shedding about the actual message :)
>> 
>> Additional testing:
>>  - [x] Ad-hoc experiments with breaking jspawnhelper
>>  - [x] macos-aarch64-server-fastdebug, `java/lang/Process java/lang/ProcessBuilder`
>
> 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 six additional commits since the last revision:
> 
>  - Add bug ID
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Pull message into a field
>  - Test cases
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Initial fix
>    
>    Good spawnhelper failure message
>    
>    Trying tests
>    
>    Print helper message on all IOExceptions
>    
>    Final

Marked as reviewed by Cynn1989 at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24149#pullrequestreview-2807908590

From shade at openjdk.org  Wed Apr 30 17:30:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Apr 2025 17:30:54 GMT
Subject: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails
 [v4]
In-Reply-To: <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com>
References: 
 <9VmHdv7PpOxbJzQngmwTEi49MULKfrn-FxVbLsj3H8U=.f54a60ee-4a92-4e99-a4ec-6ba37bd4c009@github.com>
Message-ID: 

On Wed, 30 Apr 2025 16:11:14 GMT, Aleksey Shipilev  wrote:

>> When jspawnhelper fails for whatever reason, but more prominently due to [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the errors into stdout, but not to the relevant `IOException`. So, if the application is configured to only capture the exception logs (e.g. through `java.util.logging`), we will miss any output from `jspawnhelper`, and user would be left without a clue what have happened. We have seen customers spending weeks trying to figure out what went wrong.
>> 
>> It would be good to provide useful `IOException` when `jspawnhelper` fails. We already have a precedent with vmError [printing helpful suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) when VM fails, we can do a similar thing here. 
>> 
>> I am very open to bike-shedding about the actual message :)
>> 
>> Additional testing:
>>  - [x] Ad-hoc experiments with breaking jspawnhelper
>>  - [x] macos-aarch64-server-fastdebug, `java/lang/Process java/lang/ProcessBuilder`
>
> 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 six additional commits since the last revision:
> 
>  - Add bug ID
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Pull message into a field
>  - Test cases
>  - Merge branch 'master' into JDK-8352533-jspawnhelper-ioexceptions
>  - Initial fix
>    
>    Good spawnhelper failure message
>    
>    Trying tests
>    
>    Print helper message on all IOExceptions
>    
>    Final

@tstuefe -- I know you love `jspawnhelper` bugs, want to take a look?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24149#issuecomment-2842757750

From swen at openjdk.org  Wed Apr 30 17:32:45 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 30 Apr 2025 17:32:45 GMT
Subject: RFR: 8355391: Use Long::hashCode in java.time
In-Reply-To: <35NfgP2ueIq0RkDomVTj7bLtM_R-qD7spwbhpIXNFZA=.99fab560-5969-4a75-9212-52626a3e5b62@github.com>
References: <35NfgP2ueIq0RkDomVTj7bLtM_R-qD7spwbhpIXNFZA=.99fab560-5969-4a75-9212-52626a3e5b62@github.com>
Message-ID: <2SMe9tRK7bG9W4t3Ab_4HirxijTI5J7A08IL6MUxpI8=.479bf491-69a5-4333-b8eb-ab30927f5a25@github.com>

On Wed, 30 Apr 2025 06:46:07 GMT, Volkan Yazici  wrote:

> Replace manual bitwise operations in `hashCode` implementations of `java.time` with `Long::hashCode`.

There is a place in java.util.Locale::hashCode that can also be changed
Current version

long bitsWeight = Double.doubleToLongBits(weight);
h = 37*h + (int)(bitsWeight ^ (bitsWeight >>> 32));


Can be changed to

h = 37*h + Long.hashCode(Double.doubleToLongBits(weight));

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24959#issuecomment-2842775815

From iklam at openjdk.org  Wed Apr 30 17:45:04 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 30 Apr 2025 17:45:04 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v9]
In-Reply-To: 
References: 
Message-ID: 

> This PR contains 2 parts
> 
> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.
> 
> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):
> 
> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 
> 
> `ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:
> 
> - If an entry has not yet been collected, we make sure it will never be collected.
> - If an entry has been collected, we remove it from the table
> 
> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.
> 
> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.
> 
> In the future, we may relax the implementation to allow for other use cases.

Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:

 - @AlanBateman comments
 - @xmas92 comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24757/files
  - new: https://git.openjdk.org/jdk/pull/24757/files/4aa68741..f8aff12a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24757&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24757&range=07-08

  Stats: 6 lines in 4 files changed: 1 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24757/head:pull/24757

PR: https://git.openjdk.org/jdk/pull/24757

From iklam at openjdk.org  Wed Apr 30 17:45:05 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 30 Apr 2025 17:45:05 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v8]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 30 Apr 2025 08:47:59 GMT, Axel Boldt-Christmas  wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Renamed the internal field ReferenceQueue.NULL to NULL_QUEUE to avoid failing hotspot/jtreg/sources/TestNoNULL.java
>
> src/hotspot/share/cds/aotArtifactFinder.cpp line 77:
> 
>> 75:   // into the AOT cache -- that will be decided by the code below.
>> 76:   SystemDictionaryShared::finish_exclusion_checks();
>> 77:   AOTReferenceObjSupport::init_keep_alive_objs_table();
> 
> This should be guarded with `INCLUDE_CDS_JAVA_HEAP` somehow. I guess the cleanest way would be to use `NOT_CDS_JAVA_HEAP_RETURN` in `aotReferenceObjSupport.hpp`

I added `NOT_CDS_JAVA_HEAP_RETURN` to the declaration of `init_keep_alive_objs_table`. All the other functions are called only inside `INCLUDE_CDS_JAVA_HEAP` blocks, so I didn't change them to avoid cluttering the code.

> src/hotspot/share/cds/aotReferenceObjSupport.cpp line 95:
> 
>> 93: #if INCLUDE_CDS_JAVA_HEAP
>> 94: 
>> 95: 
> 
> Suggestion:

Fixed.

> test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/WeakReferenceTest.java line 233:
> 
>> 231:         if (ref2.get() == null) {
>> 232:             throw new RuntimeException("ref2.get() should not be null");
>> 233:         }
> 
> The referent of ref2 is never strong. If a GC occurs between makeRef2() and this check, we could hit this Exception. The test should either keep it strongly reachable until after this check or just not test wether it is reachable before the call to System.gc().

I removed the check that was before the GC.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2069169854
PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2069169794
PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2069169743

From iklam at openjdk.org  Wed Apr 30 17:45:05 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 30 Apr 2025 17:45:05 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v8]
In-Reply-To: <6-qu1_BjQ41WzYq8LNM3jZTQ6jPsMP7kWVvX5wbtXk0=.8a563fda-8f4e-44e6-906a-fb829721de64@github.com>
References: 
 
 
 <6-qu1_BjQ41WzYq8LNM3jZTQ6jPsMP7kWVvX5wbtXk0=.8a563fda-8f4e-44e6-906a-fb829721de64@github.com>
Message-ID: 

On Wed, 30 Apr 2025 15:40:35 GMT, Ioi Lam  wrote:

>> src/java.base/share/classes/java/lang/ref/Reference.java line 313:
>> 
>>> 311:     }
>>> 312: 
>>> 313:     private static void runtimeSetup() {
>> 
>> I don't know if you are planning an annotation or something to mark these "runtimeSetup" methods but each one will minimally need a comment so that it's clear to anyone touching this code that it may be called by the VM when loading the AOT cache.
>
> Yes, the plan is to use annotation to mark the `runtimeSetup` and `assemblySetup` methods.

I added a comment above the new `runtimeSetup()` method in Reference.java. For the other existing occurrences, I plan to address them in a separate RFE, probably [JDK-8342481](https://bugs.openjdk.org/browse/JDK-8342481)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2069174481

From duke at openjdk.org  Wed Apr 30 17:49:45 2025
From: duke at openjdk.org (duke)
Date: Wed, 30 Apr 2025 17:49:45 GMT
Subject: RFR: 8355391: Use Long::hashCode in java.time
In-Reply-To: <35NfgP2ueIq0RkDomVTj7bLtM_R-qD7spwbhpIXNFZA=.99fab560-5969-4a75-9212-52626a3e5b62@github.com>
References: <35NfgP2ueIq0RkDomVTj7bLtM_R-qD7spwbhpIXNFZA=.99fab560-5969-4a75-9212-52626a3e5b62@github.com>
Message-ID: 

On Wed, 30 Apr 2025 06:46:07 GMT, Volkan Yazici  wrote:

> Replace manual bitwise operations in `hashCode` implementations of `java.time` with `Long::hashCode`.

@vy 
Your change (at version 891d9ada7ce6860ea8e1253021f04053cc27090a) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24959#issuecomment-2842821265

From vyazici at openjdk.org  Wed Apr 30 17:49:45 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 30 Apr 2025 17:49:45 GMT
Subject: RFR: 8355391: Use Long::hashCode in java.time
In-Reply-To: <6pFvkJpLIQVrGXgELkrnhDs3YgJ2-ufY6RaCA8kklkQ=.b565fc4c-994f-4329-994c-9ea11855e1bc@github.com>
References: <35NfgP2ueIq0RkDomVTj7bLtM_R-qD7spwbhpIXNFZA=.99fab560-5969-4a75-9212-52626a3e5b62@github.com>
 <6pFvkJpLIQVrGXgELkrnhDs3YgJ2-ufY6RaCA8kklkQ=.b565fc4c-994f-4329-994c-9ea11855e1bc@github.com>
Message-ID: 

On Wed, 30 Apr 2025 15:01:08 GMT, Roger Riggs  wrote:

>> Replace manual bitwise operations in `hashCode` implementations of `java.time` with `Long::hashCode`.
>
> lgtm

@RogerRiggs, @minborg, @naotoj, thanks for the reviews. I've attached successful `tier1,2` results to the ticket. I'd appreciate it if one of you would be kind enough to also sponsor the changes.

@wenshao, thanks for the tip. I will explore if we can perform similar simplifications in `java.util` too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24959#issuecomment-2842824998

From liach at openjdk.org  Wed Apr 30 17:53:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 17:53:50 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 30 Apr 2025 17:45:04 GMT, Ioi Lam  wrote:

>> This PR contains 2 parts
>> 
>> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
>> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.
>> 
>> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):
>> 
>> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
>> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 
>> 
>> `ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:
>> 
>> - If an entry has not yet been collected, we make sure it will never be collected.
>> - If an entry has been collected, we remove it from the table
>> 
>> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.
>> 
>> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.
>> 
>> In the future, we may relax the implementation to allow for other use cases.
>
> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - @AlanBateman comments
>  - @xmas92 comments

Thanks for the comment addition requested by Alan.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24757#pullrequestreview-2807965410

From vyazici at openjdk.org  Wed Apr 30 17:55:52 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 30 Apr 2025 17:55:52 GMT
Subject: Integrated: 8355391: Use Long::hashCode in java.time
In-Reply-To: <35NfgP2ueIq0RkDomVTj7bLtM_R-qD7spwbhpIXNFZA=.99fab560-5969-4a75-9212-52626a3e5b62@github.com>
References: <35NfgP2ueIq0RkDomVTj7bLtM_R-qD7spwbhpIXNFZA=.99fab560-5969-4a75-9212-52626a3e5b62@github.com>
Message-ID: 

On Wed, 30 Apr 2025 06:46:07 GMT, Volkan Yazici  wrote:

> Replace manual bitwise operations in `hashCode` implementations of `java.time` with `Long::hashCode`.

This pull request has now been integrated.

Changeset: 18983b63
Author:    Volkan Yazici 
Committer: Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/18983b635fe3469c1d9060611eee76e0155ba21b
Stats:     12 lines in 5 files changed: 0 ins; 5 del; 7 mod

8355391: Use Long::hashCode in java.time

Reviewed-by: rriggs, pminborg, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/24959

From duke at openjdk.org  Wed Apr 30 18:02:52 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 30 Apr 2025 18:02:52 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v9]
In-Reply-To: 
References: 
 <8SHcFyjNMhqcY0TDhwiLkCO-xottmOFa4nqeCDrglTc=.4122346e-5e83-4f40-abcf-415e33d214f0@github.com>
 
 
Message-ID: 

On Wed, 30 Apr 2025 15:47:32 GMT, Chen Liang  wrote:

>> src/java.base/share/classes/java/lang/String.java line 1739:
>> 
>>> 1737: 
>>> 1738:     /**
>>> 1739:      * {@inheritDoc CharSequence}
>> 
>> @jaikiran @jddarcy Sorry for bothering, but I do need your kind help here to get the code to exactly that shape that you want to have it. While `{@inheritDoc CharSequence}` does work very well for `StringBuilder` and `StringBuffer` (via `AbstractStringBuilder` to shorten code size), it simply doesn't have *any* effect when applied at `String`: `make docs` successfully finishes without warnings or errors, but `String.html` still contains just the link to `CharSequence` but *is missing* the copy of the JavaDoc main text. I simply do not see why. Any ideas? ?
>
> Could this be a Javadoc bug? What does a simple `{@inheritDoc}` do?

Unfortunately the same happens. ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2069198621

From jvernee at openjdk.org  Wed Apr 30 18:03:52 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 30 Apr 2025 18:03:52 GMT
Subject: RFR: 8349146: [REDO] Implement a better allocator for downcalls
 [v6]
In-Reply-To: 
References: 
 
Message-ID: <8zAGokzs5CTDvvlNRh8YRaMDChm9Qi4RCWI2SBihE3w=.ade66b03-422a-4cd2-9d1d-085d8a3cae0b@github.com>

On Wed, 30 Apr 2025 15:33:52 GMT, Per Minborg  wrote:

>> This PR is based on the work of @mernst-github and aims to implement an _internal_ thread-local 'stack' allocator, which works like a dynamically sized arena, but with reset functionality to reset the allocated size back to a certain level. The underlying memory could stay around between calls, which could improve performance.
>> 
>> Re-allocated segments are not zeroed between allocations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve on comments

src/java.base/share/classes/jdk/internal/foreign/BufferStack.java line 185:

> 183:         long size = layout.byteAlignment() > JAVA_LONG.byteSize()
> 184:                 ? Utils.alignUp(layout.byteSize(), layout.byteAlignment())
> 185:                 : layout.byteSize();

We already do this kind of conditional alignment in `SegmentFactories` (see the use of `MAX_MALLOC_ALIGN`). I suggest re-using that logic, by passing the alignment to `PerThread::of`, and then forwarding it to the `arena.allocate` call. The other overload can pass `1` as the alignment.

test/jdk/java/foreign/TestBufferStack.java line 124:

> 122:                 outOfStack = hugeFrame.allocate(4);
> 123:                 assertEquals(hugeFrame.scope(), outOfStack.scope());
> 124:                 assertTrue(outOfStack.asOverlappingSlice(stackSegment).isEmpty());

Pre-existing but: I think `segment11` can be used here, and `stackSegment` is not actually needed?

test/jdk/java/foreign/TestBufferStackStress.java line 44:

> 42: import static org.junit.jupiter.api.Assertions.*;
> 43: 
> 44: public class TestBufferStackStress extends NativeTestHelper {

I don't think this test strictly needs to extend `NativeTestHelper`.

test/jdk/java/foreign/TestBufferStackStress2.java line 98:

> 96:                         System.gc();
> 97:                     }
> 98:                     segment.get(ValueLayout.JAVA_BYTE, i);

Won't this read out of bounds? `SMALL_ALLOC_SIZE` is only 8.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2068999305
PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2068978694
PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2069007343
PR Review Comment: https://git.openjdk.org/jdk/pull/24829#discussion_r2069198088

From liach at openjdk.org  Wed Apr 30 18:03:29 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 18:03:29 GMT
Subject: RFR: 8355956: Prepare javap for class file format aware access
 flag parsing [v2]
In-Reply-To: 
References: 
Message-ID: 

> A prerequisite to #24760; this was part of it, but was split out to simplify the review of the addition of `maskToAccessFlags(int, Location, CFFV)` by minimizing the changes in javap. That patch will only need to update `BasicWriter` as a result.
> 
> Testing: langtools/tools/javap, tier 1+2 underway

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:

 - Adapt the location APIs
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/javap-cffv-access-flags
 - 8355956: Prepare javap for class file format aware access flag parsing

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24955/files
  - new: https://git.openjdk.org/jdk/pull/24955/files/fa4001c4..b3af1964

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24955&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24955&range=00-01

  Stats: 7513 lines in 126 files changed: 6677 ins; 333 del; 503 mod
  Patch: https://git.openjdk.org/jdk/pull/24955.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24955/head:pull/24955

PR: https://git.openjdk.org/jdk/pull/24955

From iklam at openjdk.org  Wed Apr 30 18:08:54 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 30 Apr 2025 18:08:54 GMT
Subject: RFR: 8354897: Support Soft/Weak Reference in AOT cache [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 30 Apr 2025 17:45:04 GMT, Ioi Lam  wrote:

>> This PR contains 2 parts
>> 
>> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
>> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.
>> 
>> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):
>> 
>> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
>> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 
>> 
>> `ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:
>> 
>> - If an entry has not yet been collected, we make sure it will never be collected.
>> - If an entry has been collected, we remove it from the table
>> 
>> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.
>> 
>> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.
>> 
>> In the future, we may relax the implementation to allow for other use cases.
>
> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - @AlanBateman comments
>  - @xmas92 comments

Thanks everyone for the review. Passed tiers 1-4, as well as the `".*aot.jdkcache.*"` tasks up to tier 10.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24757#issuecomment-2842867410

From iklam at openjdk.org  Wed Apr 30 18:08:56 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 30 Apr 2025 18:08:56 GMT
Subject: Integrated: 8354897: Support Soft/Weak Reference in AOT cache
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Apr 2025 18:31:05 GMT, Ioi Lam  wrote:

> This PR contains 2 parts
> 
> - Upstream of Soft/Weak Reference support authored by @macarte from [the Leyden repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
> - New C++ class `AOTReferenceObjSupport` and new Java method `ReferencedKeyMap::prepareForAOTCache()` developed by @iklam on the advice of @fisk from the GC team. These control the lifecycles of reference objects during the assembly phase to simplify the implementation.
> 
> One problem we faced in this PR is the handling of Reference objects that are waiting for clean up. Currently, the only cached Reference objects that require clean up are the `WeakReferenceKey`s  used by `ReferencedKeyMap` (which is used by `MethodType::internTable`):
> 
> - When the referent of a `WeakReferenceKey` K has been collected, the key will be placed on `Universe::reference_pending_list()`. It's linked to other pending references with the `Reference::discovered` field. At this point, K is still stored in the `ReferencedKeyMap`.
> - When heapShared.cpp discovered the `ReferencedKeyMap`, it will discover K, and it may also discover other pending references that are not intended for the AOT cache. As a result, we end up caching unnecessary objects. 
> 
> `ReferencedKeyMap::prepareForAOTCache()`  avoids the above problem. It goes over all entries in the table:
> 
> - If an entry has not yet been collected, we make sure it will never be collected.
> - If an entry has been collected, we remove it from the table
> 
> Therefore, by the time heapShared.cpp starts scanning the `ReferencedKeyMap`, it will never see any keys that are on the pending list, so we will not see unintended objects.
> 
> This implementation is the very first step of Reference support in the AOT cache, so we chose a simplified approach that makes no assumptions on when the pending reference list is processed. This is sufficient for the current set of references objects in the AOT cache.
> 
> In the future, we may relax the implementation to allow for other use cases.

This pull request has now been integrated.

Changeset: 1ff7e813
Author:    Mat Carter 
Committer: Ioi Lam 
URL:       https://git.openjdk.org/jdk/commit/1ff7e813e39d16376baccdbd9e7075035248319d
Stats:     981 lines in 23 files changed: 804 ins; 107 del; 70 mod

8354897: Support Soft/Weak Reference in AOT cache

Co-authored-by: Ioi Lam 
Reviewed-by: liach, eosterlund

-------------

PR: https://git.openjdk.org/jdk/pull/24757

From liach at openjdk.org  Wed Apr 30 18:17:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 18:17:27 GMT
Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to
 class file version [v6]
In-Reply-To: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
Message-ID: 

> Take the class file version to reject flags not yet defined, redefined, or obsoleted. This is useful for clients like javap to report the correct undefined flags for different class file versions.
> 
> A preparatory patch for javap to pass around the ClassFileFormatVersion to parse flags is available at #24955.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:

 - review: improve comments about implicit null checks
 - Merge branch 'fix/javap-cffv-access-flags' into feature/af-cffv-parse
 - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
 - Explicit imports
 - Wording updates
 - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
 - Update specs for other existing APIs
 - Wording updates, thanks Roger
 - Missing since
 - Fix javap causing strictfp tests to fail
 - ... and 17 more: https://git.openjdk.org/jdk/compare/b3af1964...10be287f

-------------

Changes: https://git.openjdk.org/jdk/pull/24760/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24760&range=05
  Stats: 159 lines in 10 files changed: 99 ins; 23 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/24760.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24760/head:pull/24760

PR: https://git.openjdk.org/jdk/pull/24760

From liach at openjdk.org  Wed Apr 30 18:17:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 18:17:27 GMT
Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to
 class file version [v5]
In-Reply-To: 
References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
 
Message-ID: 

On Tue, 29 Apr 2025 19:48:01 GMT, Chen Liang  wrote:

>> Take the class file version to reject flags not yet defined, redefined, or obsoleted. This is useful for clients like javap to report the correct undefined flags for different class file versions.
>> 
>> A preparatory patch for javap to pass around the ClassFileFormatVersion to parse flags is available at #24955.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - Wording updates
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - Missing since
>  - Fix javap causing strictfp tests to fail
>  - Further furnish docs
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-cffv-parse
>  - Redundant method
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/1a22005e...41989440

Rolling back to draft while this waits for the javap changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24760#issuecomment-2840298105

From rriggs at openjdk.org  Wed Apr 30 19:05:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 30 Apr 2025 19:05:53 GMT
Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to
 class file version [v6]
In-Reply-To: 
References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
 
Message-ID: 

On Wed, 30 Apr 2025 18:17:27 GMT, Chen Liang  wrote:

>> Take the class file version to reject flags not yet defined, redefined, or obsoleted. This is useful for clients like javap to report the correct undefined flags for different class file versions.
>> 
>> A preparatory patch for javap to pass around the ClassFileFormatVersion to parse flags is available at #24955.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:
> 
>  - review: improve comments about implicit null checks
>  - Merge branch 'fix/javap-cffv-access-flags' into feature/af-cffv-parse
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - Explicit imports
>  - Wording updates
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - Update specs for other existing APIs
>  - Wording updates, thanks Roger
>  - Missing since
>  - Fix javap causing strictfp tests to fail
>  - ... and 17 more: https://git.openjdk.org/jdk/compare/b3af1964...10be287f

lgtm

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24760#pullrequestreview-2808132607

From lancea at openjdk.org  Wed Apr 30 19:21:52 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 30 Apr 2025 19:21:52 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v7]
In-Reply-To: 
References: 
 <7-hlRi4K3O2f8GbvfOy7Znvvgwyr8pP9BRaIIn4yikM=.1abe74c0-ac9c-447a-956e-49c2d5a93c39@github.com>
 <58DGueeNtyr2dvz3mpHtkN-0IwTBob7FTE7qSxf4-Tw=.eaf788a7-ed25-4551-95e9-7bda041a366b@github.com>
 
Message-ID: 

On Wed, 30 Apr 2025 14:20:37 GMT, Jaikiran Pai  wrote:

>> test/jdk/java/util/zip/ZipFile/ZipFileCharsetTest.java line 68:
>> 
>>> 66:         // ISO-8859-15 is not a standard charset in Java. We skip this test
>>> 67:         // when it is unavailable
>>> 68:         assumeTrue(Charset.availableCharsets().containsKey(ISO_8859_15_NAME),
>> 
>> I would suggest throwing SkippedException otherwise junit throws org.opentest4j.TestAbortedException  If I understand correctly
>
> Hello Lance, I was under the impression that the jtreg framework would mark an aborted junit test as skipped. Now that you mentioned this, I checked locally and in its current form, jtreg reports this test as:
> 
> 
> STARTED    ZipFileCharsetTest::testCachedZipFileSource 'testCachedZipFileSource()'
> org.opentest4j.TestAbortedException: Assumption failed: skipping test since ISO-8859-15 charset isn't available
> ABORTED    ZipFileCharsetTest::testCachedZipFileSource 'testCachedZipFileSource()' [37ms]
> 
> [ JUnit Containers: found 4, started 4, succeeded 4, failed 0, aborted 0, skipped 0]
> [ JUnit Tests: found 1, started 1, succeeded 0, failed 0, aborted 1, skipped 0]
> 
> 
> 
> 
> So it's being classified by jtreg as aborted instead of skipped. 
> 
> I then took your suggestion to throw `jtreg.SkippedException`:
> 
> 
> +import jtreg.SkippedException;
> -import static org.junit.jupiter.api.Assumptions.assumeTrue;
>  
> + * @library /test/lib
>   * @run junit ZipFileCharsetTest
>   */
>  public class ZipFileCharsetTest {
>  
>          // ISO-8859-15 is not a standard charset in Java. We skip this test
>          // when it is unavailable
> -        assumeTrue(Charset.availableCharsets().containsKey(ISO_8859_15_NAME),
> -                "skipping test since " + ISO_8859_15_NAME + " charset isn't available");
> +        if (!Charset.availableCharsets().containsKey(ISO_8859_15_NAME)) {
> +            throw new SkippedException("skipping test since " + ISO_8859_15_NAME
> +                    + " charset isn't available");
> +        }
> 
> 
> 
> That however makes jtreg mark this test as failed instead of skipped:
> 
> 
> STARTED    ZipFileCharsetTest::testCachedZipFileSource 'testCachedZipFileSource()'
> jtreg.SkippedException: skipping test since ISO-8859-15 charset isn't available
>     at ZipFileCharsetTest.testCachedZipFileSource(ZipFileCharsetTest.java:70)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>     at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
>     at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
> FAILED     ZipFileCharsetTest::testCachedZipFileSource 'testCachedZipFileSource()' [28ms]
> JavaTest Message: JUnit Platform Failure(s): 1
> 
> [ JUnit Containers: found 4, started 4, succeeded 4, failed 0, aborted 0, skipped 0]
> [ JUnit Tests: found 1, started 1, succeeded 0, failed 1, aborted 0, skipped 0]
> 
> 
> So it looks like we have an issue here with jtreg when it runs a junit test and the test throws `jtreg.SkippedException`. There appears to be an open issue for that (although in context o...

Hi Jai,

It is the lessor of 2 evils WRT the reporting isn't it.    It is unfortunate that this feature is not working.  I think throwing the SkippedException is the right way to go long term but I assume this shows as a reported failure in Mach5 and in the case of assumeTrue it does not result in a failure being reported?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2069306532

From mli at openjdk.org  Wed Apr 30 19:46:26 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 30 Apr 2025 19:46:26 GMT
Subject: RFR: 8355698: JDK not supporting sleef could cause exception at
 runtime after JDK-8353786
Message-ID: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com>

Hi,
Can you help to review this patch?

Before [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), when a released jdk not supportting sleef (for any reason, e.g. low gcc version, intrinsic not supported, rvv not supported, and so on) runs on machine support vector operation (e.g. on riscv, it supports rvv), it can not call into sleef, but will not fail either, it falls back to java scalar version implementation.
But after [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), it will cause an exception thrown at runtime.

This change the behaviour of existing jdk, and it should not throw exception anyway.

@iwanowww @RealFYang 

Thanks!

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/24914/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24914&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355698
  Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24914/head:pull/24914

PR: https://git.openjdk.org/jdk/pull/24914

From vlivanov at openjdk.org  Wed Apr 30 19:46:26 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 30 Apr 2025 19:46:26 GMT
Subject: RFR: 8355698: JDK not supporting sleef could cause exception at
 runtime after JDK-8353786
In-Reply-To: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com>
References: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com>
Message-ID: 

On Mon, 28 Apr 2025 10:34:49 GMT, Hamlin Li  wrote:

> Hi,
> Can you help to review this patch?
> 
> Before [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), when a released jdk not supportting sleef (for any reason, e.g. low gcc version, intrinsic not supported, rvv not supported, and so on) runs on machine support vector operation (e.g. on riscv, it supports rvv), it can not call into sleef, but will not fail either, it falls back to java scalar version implementation.
> But after [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), it will cause an exception thrown at runtime.
> 
> This change the behaviour of existing jdk, and it should not throw exception anyway.
> 
> @iwanowww @RealFYang 
> 
> Thanks!

The assumption is if vector math library is present, it provides full set of stubs. 

Do we really want to complicate things even more by supporting arbitrary subsets of vector math stubs?

IMO a better way to fix the problem is to avoid building/bundling SLEEF when any stubs are missing.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24914#pullrequestreview-2801649899

From syan at openjdk.org  Wed Apr 30 19:46:26 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 30 Apr 2025 19:46:26 GMT
Subject: RFR: 8355698: JDK not supporting sleef could cause exception at
 runtime after JDK-8353786
In-Reply-To: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com>
References: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com>
Message-ID: 

On Mon, 28 Apr 2025 10:34:49 GMT, Hamlin Li  wrote:

> Hi,
> Can you help to review this patch?
> 
> Before [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), when a released jdk not supportting sleef (for any reason, e.g. low gcc version, intrinsic not supported, rvv not supported, and so on) runs on machine support vector operation (e.g. on riscv, it supports rvv), it can not call into sleef, but will not fail either, it falls back to java scalar version implementation.
> But after [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), it will cause an exception thrown at runtime.
> 
> This change the behaviour of existing jdk, and it should not throw exception anyway.
> 
> @iwanowww @RealFYang 
> 
> Thanks!

This PR can fix the failure of [JDK-8355656](https://bugs.openjdk.org/browse/JDK-8355656)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24914#issuecomment-2837289061

From mli at openjdk.org  Wed Apr 30 19:46:26 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 30 Apr 2025 19:46:26 GMT
Subject: RFR: 8355698: JDK not supporting sleef could cause exception at
 runtime after JDK-8353786
In-Reply-To: 
References: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com>
 
Message-ID: <3BMQiQtyRXIj-NFUoFPliNYV4r1nX3KpKgniMvtOMkc=.cdcd240e-ce85-46c7-9bfb-e5be5124aae9@github.com>

On Tue, 29 Apr 2025 02:40:01 GMT, SendaoYan  wrote:

>> Hi,
>> Can you help to review this patch?
>> 
>> Before [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), when a released jdk not supportting sleef (for any reason, e.g. low gcc version, intrinsic not supported, rvv not supported, and so on) runs on machine support vector operation (e.g. on riscv, it supports rvv), it can not call into sleef, but will not fail either, it falls back to java scalar version implementation.
>> But after [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), it will cause an exception thrown at runtime.
>> 
>> This change the behaviour of existing jdk, and it should not throw exception anyway.
>> 
>> @iwanowww @RealFYang 
>> 
>> Thanks!
>
> This PR can fix the failure of [JDK-8355656](https://bugs.openjdk.org/browse/JDK-8355656)

I think, first [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786) changes the behaviour of jdk (previously it does not throw exception or fail in other ways). second it should fall back to a java implementation rather than fail, this is more friendly to jdk vendors and users. As you can see, @sendaoYan report another issue related to it on x64 platform.

For the jdk vendors, I suppose they should try their best to build a jdk with full vector math library support, but they can fail to do so for many reasons, in that situation we should fall back to a default version which could be slow in performance, but should not fail, because we already has a java scalar version implemented, and the motivation of this version is for falling back when there is no optimal native version.

> The assumption is if vector math library is present, it provides full set of stubs.

Yes. The issues here is the released jdk could be lack of support of such library for various reasons.

> Do we really want to complicate things even more by supporting arbitrary subsets of vector math stubs?

I'm not sure what you mean here, but seems to me the fix is simple, we just not throw exception and allow it fall back to java scalar version, and this behaviour is consitent with previous jdk behaviour. Or can you clarify further?

> IMO a better way to fix the problem is to avoid building/bundling SLEEF when any stubs are missing.

This behavour was decided in previous PRs https://github.com/openjdk/jdk/pull/20781, https://github.com/openjdk/jdk/pull/21083, https://github.com/openjdk/jdk/pull/21502, and some other uncommited PRs prior to these ones.
And the x64 math libraray support (SVML) in jdk was introduced even earlier.

How do you think about it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24914#issuecomment-2838053586

From vlivanov at openjdk.org  Wed Apr 30 19:46:26 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 30 Apr 2025 19:46:26 GMT
Subject: RFR: 8355698: JDK not supporting sleef could cause exception at
 runtime after JDK-8353786
In-Reply-To: <3BMQiQtyRXIj-NFUoFPliNYV4r1nX3KpKgniMvtOMkc=.cdcd240e-ce85-46c7-9bfb-e5be5124aae9@github.com>
References: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com>
 
 <3BMQiQtyRXIj-NFUoFPliNYV4r1nX3KpKgniMvtOMkc=.cdcd240e-ce85-46c7-9bfb-e5be5124aae9@github.com>
Message-ID: 

On Tue, 29 Apr 2025 09:16:39 GMT, Hamlin Li  wrote:

> This behavour was decided in previous PRs https://github.com/openjdk/jdk/pull/20781, https://github.com/openjdk/jdk/pull/21083, https://github.com/openjdk/jdk/pull/21502, and some other uncommited PRs prior to these ones.

Can you point me, please, to the relevant parts of the discussions? I wasn't part of them.

>> Do we really want to complicate things even more by supporting arbitrary subsets of vector math stubs?
> I'm not sure what you mean here, but seems to me the fix is simple, we just not throw exception and allow it fall back to java scalar version, and this behaviour is consitent with previous jdk behaviour. Or can you clarify further?

Both SVML and SLEEF-based vector math native libraries are built and bundled with the JDK. JDK is in full control of their sources and should be able to rely on the exact API they expose. 

Such behavior has a number of advantages, in particular:
  * exposes bugs (missing entries, naming mismatches between JDK and vector math library);
  * enables future evolution towards jextract-based automatic Java API extraction (based on library header files)

API variability complicates things, so should be avoided unless there are compelling reasons to justify it. Can you summarize, please, what's the motivation behind such behavior?

If build platform doesn't fully satisfy library requirements, the library can be excluded. If the library is missing, default (Java) implementations are used.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24914#issuecomment-2840370110

From mli at openjdk.org  Wed Apr 30 19:46:26 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 30 Apr 2025 19:46:26 GMT
Subject: RFR: 8355698: JDK not supporting sleef could cause exception at
 runtime after JDK-8353786
In-Reply-To: 
References: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com>
 
 <3BMQiQtyRXIj-NFUoFPliNYV4r1nX3KpKgniMvtOMkc=.cdcd240e-ce85-46c7-9bfb-e5be5124aae9@github.com>
 
Message-ID: 

On Tue, 29 Apr 2025 22:22:19 GMT, Vladimir Ivanov  wrote:

> Can you point me, please, to the relevant parts of the discussions? I wasn't part of them.

Sorry, I can not find out this specific answer for you, as there were too long discussion there, the whole process took several months.

> Both SVML and SLEEF-based vector math native libraries are built and bundled with the JDK. JDK is in full control of their sources and should be able to rely on the exact API they expose.

Seems both jdk vendors and jdk end users don't have a full control of the environment to opposite sides.

>   exposes bugs (missing entries, naming mismatches between JDK and vector math library);

It's arguable if missing entries is a bug, please check [JDK-8355656](https://bugs.openjdk.org/browse/JDK-8355656) for example

>   enables future evolution towards jextract-based automatic Java API extraction (based on library header files)

I'm not familar with this feature, but could it be simple to catch a missing API, then do some necessary things?

> API variability complicates things, so should be avoided unless there are compelling reasons to justify it. Can you summarize, please, what's the motivation behind such behavior?

One advantage of it is fault tolerance, please check [JDK-8355656](https://bugs.openjdk.org/browse/JDK-8355656) for example. And I don't think this compliates things.

> If build platform doesn't fully satisfy library requirements, the library can be excluded.

Does [JDK-8355656](https://bugs.openjdk.org/browse/JDK-8355656) fall in the above scenario? Why should we exclude the whole library when only part of the library is not supported?
After all we does not support TANH on riscv and arm for now.

In summary, I'm concerned that there could always be some potential issue, and we should consider to make it fall back when we could, as after a jdk release to end users it's out of your control. If we want to consider these things ( like missing entries as bugs, we still could do it in other ways (like checking the log in a test), rather than totally stop the jdk to run in end users' environment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24914#issuecomment-2841606017

From zuniquex at protonmail.com  Wed Apr 30 19:46:44 2025
From: zuniquex at protonmail.com (=?utf-8?Q?Steffen_Nie=C3=9Fing?=)
Date: Wed, 30 Apr 2025 19:46:44 +0000
Subject: JavaDoc fix in java.util.Date
Message-ID: 

Hello,

I'm new to the OpenJDK community and plan to make my first change.

I've found a small mistake in the documentation of java.util.Date#hashCode(). The documentation provides a Java expression of the returned value, which uses a non-existent operator '>>>'.

Now I'm searching for a sponsor for a JBS issue and the code review. Chen Liang directed me to this mailing list to ask for sponsoring on this topic.

Cheers,
Steffen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vlivanov at openjdk.org  Wed Apr 30 19:46:26 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 30 Apr 2025 19:46:26 GMT
Subject: RFR: 8355698: JDK not supporting sleef could cause exception at
 runtime after JDK-8353786
In-Reply-To: 
References: <3qrRGcALYWJvERlVlpAkt0BOaYSmc27VpWLACT2NuBo=.de92478d-5bf7-4c83-8b91-2729ac531134@github.com>
 
 <3BMQiQtyRXIj-NFUoFPliNYV4r1nX3KpKgniMvtOMkc=.cdcd240e-ce85-46c7-9bfb-e5be5124aae9@github.com>
 
 
Message-ID: <1hfhvGjxKFAYEtj1D_pIdgU659AE2oPWoQEyXl8sRgQ=.3aa62617-142a-49c9-82c4-0f761cb73aff@github.com>

On Wed, 30 Apr 2025 11:00:04 GMT, Hamlin Li  wrote:

> It's arguable if missing entries is a bug, please check [JDK-8355656](https://bugs.openjdk.org/browse/JDK-8355656) for example

Personally, I'm surprised SVML is affected in a similar way because stubs are provided in assembly form, so they are simply linked into a shared library during assembly phase. I can only guess what causes such inconsistencies during JDK build phase. And it just reassures me that current behavior is a source of bugs in the future.

Overall, it still looks like a JDK build issue to me. Hiding problems occurred during the build is not good. If some toolchains can't successfully build the library, the library shouldn't be included in JDK.  

> After all we does not support TANH on riscv and arm for now.

JDK code is aware of that and doesn't try to look up corresponding entries. Ideally, it shouldn't be included into the native library, since it increases its size for no good reason. But having unused code is a redundancy and not a bug per se.

(For SVML it's a bit more complicated, because JDK is the only place where sources of SVML stubs live (there's no upstream project/distribution)).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24914#issuecomment-2843093609

From joe.darcy at oracle.com  Wed Apr 30 19:54:04 2025
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 30 Apr 2025 12:54:04 -0700
Subject: JavaDoc fix in java.util.Date
In-Reply-To: 
References: 
Message-ID: 

Unsigned right shift is non-existent?

"The operators << (left shift), >> (signed right shift), and >>> 
(unsigned right shift) are called the shift operators. The left-hand 
operand of a shift operator is the value to be shifted; the right-hand 
operand specifies the shift distance. "

https://docs.oracle.com/javase/specs/jls/se24/html/jls-15.html#jls-15.19

-Joe

On 4/30/2025 12:46 PM, Steffen Nie?ing wrote:
> Hello,
>
> I'm new to the OpenJDK community and plan to make my first change.
>
> I've found a small mistake in the documentation of 
> java.util.Date#hashCode(). The documentation provides a Java 
> expression of the returned value, which uses a non-existent operator 
> '>>>'.
>
> Now I'm searching for a sponsor for a JBS issue and the code review. 
> Chen Liang directed me to this mailing list to ask for sponsoring on 
> this topic.
>
> Cheers,
> Steffen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From chen.l.liang at oracle.com  Wed Apr 30 20:06:57 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Wed, 30 Apr 2025 20:06:57 +0000
Subject: JavaDoc fix in java.util.Date
In-Reply-To: 
References: 
 
Message-ID: 

Indeed, Joe is right. Unsigned right shift does not appear often and is equivalent to signed right shift if the sign bit is 0.

However, this piece of quote can get an upgrade - it can become `Long.hashCode(this.getTime())`.


  *
Chen

________________________________
From: core-libs-dev  on behalf of Joseph D. Darcy 
Sent: Wednesday, April 30, 2025 2:54 PM
To: Steffen Nie?ing ; core-libs-dev at openjdk.org 
Subject: Re: JavaDoc fix in java.util.Date

Unsigned right shift is non-existent?

"The operators << (left shift), >> (signed right shift), and >>> (unsigned right shift) are called the shift operators. The left-hand operand of a shift operator is the value to be shifted; the right-hand operand specifies the shift distance. "

https://docs.oracle.com/javase/specs/jls/se24/html/jls-15.html#jls-15.19

-Joe

On 4/30/2025 12:46 PM, Steffen Nie?ing wrote:
Hello,

I'm new to the OpenJDK community and plan to make my first change.

I've found a small mistake in the documentation of java.util.Date#hashCode(). The documentation provides a Java expression of the returned value, which uses a non-existent operator '>>>'.

Now I'm searching for a sponsor for a JBS issue and the code review. Chen Liang directed me to this mailing list to ask for sponsoring on this topic.

Cheers,
Steffen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From naoto.sato at oracle.com  Wed Apr 30 20:11:52 2025
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 30 Apr 2025 13:11:52 -0700
Subject: JavaDoc fix in java.util.Date
In-Reply-To: 
References: 
 
 
Message-ID: 

Interestingly, the implementation of Date.hashCode() does use the signed 
right shift ">>".

Naoto

On 4/30/25 1:06 PM, Chen Liang wrote:
> Indeed, Joe is right. Unsigned right shift does not appear often and is 
> equivalent to signed right shift if the sign bit is 0.
> 
> However, this piece of quote can get an upgrade - it can become 
> `Long.hashCode(this.getTime())`.
> 
>   *
>     Chen
> 
> ------------------------------------------------------------------------
> *From:* core-libs-dev  on behalf of 
> Joseph D. Darcy 
> *Sent:* Wednesday, April 30, 2025 2:54 PM
> *To:* Steffen Nie?ing ; core-libs- 
> dev at openjdk.org 
> *Subject:* Re: JavaDoc fix in java.util.Date
> Unsigned right shift is non-existent?
> 
> "The operators << (left shift), >> (signed right shift), and >>> 
> (unsigned right shift) are called the shift operators. The left-hand 
> operand of a shift operator is the value to be shifted; the right-hand 
> operand specifies the shift distance. "
> 
> https://docs.oracle.com/javase/specs/jls/se24/html/jls-15.html#jls-15.19 
> 
> 
> -Joe
> 
> On 4/30/2025 12:46 PM, Steffen Nie?ing wrote:
>> Hello,
>>
>> I'm new to the OpenJDK community and plan to make my first change.
>>
>> I've found a small mistake in the documentation of 
>> java.util.Date#hashCode(). The documentation provides a Java 
>> expression of the returned value, which uses a non-existent operator 
>> '>>>'.
>>
>> Now I'm searching for a sponsor for a JBS issue and the code review. 
>> Chen Liang directed me to this mailing list to ask for sponsoring on 
>> this topic.
>>
>> Cheers,
>> Steffen
> 
> 


From almatvee at openjdk.org  Wed Apr 30 20:21:56 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 30 Apr 2025 20:21:56 GMT
Subject: RFR: 8352480: [macos] Don't follow symlinks in additional content for
 app images
Message-ID: 

- Symbolic links will not be followed for `--app-content` on macOS.
- Added test to cover this case.
- `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, since "cp -r" on macOS is not documented option and when used `cp` will follow symbolic links which breaks test. "cp -R" does not follow symbolic links.

-------------

Commit messages:
 - 8352480: [macos] Don't follow symlinks in additional content for app images

Changes: https://git.openjdk.org/jdk/pull/24974/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24974&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352480
  Stats: 56 lines in 3 files changed: 30 ins; 16 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/24974.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24974/head:pull/24974

PR: https://git.openjdk.org/jdk/pull/24974

From liach at openjdk.org  Wed Apr 30 20:26:33 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 20:26:33 GMT
Subject: RFR: 8351996: Behavioral updates for ClassValue::remove [v11]
In-Reply-To: 
References: 
Message-ID: 

> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
> 
> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
> 
> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
> 
> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.

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 19 additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
 - Reviews from viktor
 - Rewrite impl to follow the new simplified spec
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
 - Try to simplify the model - use the finish of computeValue
   
 - Test updates - remove repetition, test case for no stale installation
 - Fix incorrect promise removal when unnecessary and add regression test
 - Cannot test for recursion eagerly - add test case
 - More spec, eager exception, finish with existing, thanks John
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
 - ... and 9 more: https://git.openjdk.org/jdk/compare/31bab6cf...2292212b

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24043/files
  - new: https://git.openjdk.org/jdk/pull/24043/files/221d51e7..2292212b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=09-10

  Stats: 8959 lines in 206 files changed: 7551 ins; 638 del; 770 mod
  Patch: https://git.openjdk.org/jdk/pull/24043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24043/head:pull/24043

PR: https://git.openjdk.org/jdk/pull/24043

From bchristi at openjdk.org  Wed Apr 30 20:27:31 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 30 Apr 2025 20:27:31 GMT
Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed
 with "RuntimeException: MyObject is not found in test output" [v8]
In-Reply-To: 
References: 
Message-ID: 

> I propose some cleanups to `FinalizerHistogramTest.java` to hopefully clear up the intermittent failures:
> 
> * run with `othervm`: this test blocks the (global) finalizer thread, and also requires the (global) finalizer thread to enter the test's `finalize()` method
> * The test uses `volatile` ints, but sets them based on their current value, which is not reliable; convert to `AtomicInteger`
> * use `PhantomReference`s to ensure that at least two `MyObject`s have become unreachable. If one is stuck in `finalize()`, at least one is still waiting to be finalized and should show up in the histogram.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  loop until ref proc returns false

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24143/files
  - new: https://git.openjdk.org/jdk/pull/24143/files/10c8a9e3..0468fe73

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24143&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24143&range=06-07

  Stats: 7 lines in 1 file changed: 4 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24143/head:pull/24143

PR: https://git.openjdk.org/jdk/pull/24143

From bchristi at openjdk.org  Wed Apr 30 20:27:31 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 30 Apr 2025 20:27:31 GMT
Subject: RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed
 with "RuntimeException: MyObject is not found in test output" [v7]
In-Reply-To: <1tGRJ4ejgEBN_prDxdLQajmtGU4whVg5OAH8ziKR3pQ=.9b4a8e19-0fec-43a3-a357-4f63d6f7078c@github.com>
References: 
 
 <1tGRJ4ejgEBN_prDxdLQajmtGU4whVg5OAH8ziKR3pQ=.9b4a8e19-0fec-43a3-a357-4f63d6f7078c@github.com>
Message-ID: 

On Tue, 29 Apr 2025 23:16:05 GMT, Kim Barrett  wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   convert test to use WhiteBox
>
> test/jdk/java/lang/ref/FinalizerHistogramTest.java line 77:
> 
>> 75:             wb = WhiteBox.getWhiteBox();
>> 76:             wb.fullGC();
>> 77:             refProResult = wb.waitForReferenceProcessing();
> 
> WhiteBox::waitForReferenceProcessing returns true if some progress has been made, not if all the 
> processing is done.  Probably need a loop here, e.g.
> 
> while (wb.waitForReferenceProcessing()) {}
> // All finalizable objects from prior gcs have made it to the finalizer queue.

I've only ever seen it return `false`. But that won't necessarily always be true; I've added a loop.

> test/jdk/java/lang/ref/FinalizerHistogramTest.java line 79:
> 
>> 77:             refProResult = wb.waitForReferenceProcessing();
>> 78:             System.out.println("waitForReferenceProcessing returned: " + refProResult);
>> 79:             while(trappedCount.get() < 1);
> 
> This doesn't seem to be doing anything?  trappedCount is initially 0, and only incremented.

It spins until at least one `MyObject` has entered `finalize()` before proceeding to fetch the histogram.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24143#discussion_r2069386677
PR Review Comment: https://git.openjdk.org/jdk/pull/24143#discussion_r2069389317

From chen.l.liang at oracle.com  Wed Apr 30 20:27:44 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Wed, 30 Apr 2025 20:27:44 +0000
Subject: JavaDoc fix in java.util.Date
In-Reply-To: 
References: 
 
 
 
Message-ID: 

Well, the sign has no impact here - the most significant 32 bits duplicated from the original sign bit are immediately discarded in the subsequent int cast truncation to the least significant 32 bits. However, how there is such a difference from before OpenJDK was published is still intriguing.
________________________________
From: core-libs-dev  on behalf of Naoto Sato 
Sent: Wednesday, April 30, 2025 3:11 PM
To: core-libs-dev at openjdk.org 
Subject: Re: JavaDoc fix in java.util.Date

Interestingly, the implementation of Date.hashCode() does use the signed
right shift ">>".

Naoto

On 4/30/25 1:06 PM, Chen Liang wrote:
> Indeed, Joe is right. Unsigned right shift does not appear often and is
> equivalent to signed right shift if the sign bit is 0.
>
> However, this piece of quote can get an upgrade - it can become
> `Long.hashCode(this.getTime())`.
>
>   *
>     Chen
>
> ------------------------------------------------------------------------
> *From:* core-libs-dev  on behalf of
> Joseph D. Darcy 
> *Sent:* Wednesday, April 30, 2025 2:54 PM
> *To:* Steffen Nie?ing ; core-libs-
> dev at openjdk.org 
> *Subject:* Re: JavaDoc fix in java.util.Date
> Unsigned right shift is non-existent?
>
> "The operators << (left shift), >> (signed right shift), and >>>
> (unsigned right shift) are called the shift operators. The left-hand
> operand of a shift operator is the value to be shifted; the right-hand
> operand specifies the shift distance. "
>
> https://docs.oracle.com/javase/specs/jls/se24/html/jls-15.html#jls-15.19
> 
>
> -Joe
>
> On 4/30/2025 12:46 PM, Steffen Nie?ing wrote:
>> Hello,
>>
>> I'm new to the OpenJDK community and plan to make my first change.
>>
>> I've found a small mistake in the documentation of
>> java.util.Date#hashCode(). The documentation provides a Java
>> expression of the returned value, which uses a non-existent operator
>> '>>>'.
>>
>> Now I'm searching for a sponsor for a JBS issue and the code review.
>> Chen Liang directed me to this mailing list to ask for sponsoring on
>> this topic.
>>
>> Cheers,
>> Steffen
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Wed Apr 30 20:35:19 2025
From: duke at openjdk.org (Gautham Krishnan)
Date: Wed, 30 Apr 2025 20:35:19 GMT
Subject: RFR: 8334742: Change java.time month/day field types to 'byte'
Message-ID: 

In the following classes, month and day values are stored in fields of type 'int' or 'short'. The range of allowed values is small enough that the type can be 'byte' instead.

java.time.YearMonth
java.time.MonthDay
java.time.LocalDate
java.time.chono.HijrahDate

Refactoring the type will give the JVM a little more layout flexibility, and will be especially useful when these classes become value classes.

-------------

Commit messages:
 - Changing month and day value data type to byte

Changes: https://git.openjdk.org/jdk/pull/24975/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24975&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334742
  Stats: 16 lines in 4 files changed: 0 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/24975.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24975/head:pull/24975

PR: https://git.openjdk.org/jdk/pull/24975

From zuniquex at protonmail.com  Wed Apr 30 20:37:17 2025
From: zuniquex at protonmail.com (=?utf-8?Q?Steffen_Nie=C3=9Fing?=)
Date: Wed, 30 Apr 2025 20:37:17 +0000
Subject: JavaDoc fix in java.util.Date
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

Thanks, haven't seen unsigned right shift before. You're right, it should be fine to use the unsigned one and hence Long.hashCode for that.

However, the docs should match the expression used in the implementation when explicitly naming the returned expression. Should we update both to Long.hashCode(this.getTime())?

Cheers,
Steffen

Chen Liang  schrieb am Mittwoch, 30. April 2025 um 22:27:

> Well, the sign has no impact here - the most significant 32 bits duplicated from the original sign bit are immediately discarded in the subsequent int cast truncation to the least significant 32 bits. However, how there is such a difference from before OpenJDK was published is still intriguing.
>
> ---------------------------------------------------------------
>
> From: core-libs-dev  on behalf of Naoto Sato 
> Sent: Wednesday, April 30, 2025 3:11 PM
> To: core-libs-dev at openjdk.org 
> Subject: Re: JavaDoc fix in java.util.Date
>
> Interestingly, the implementation of Date.hashCode() does use the signed
> right shift ">>".
>
> Naoto
>
> On 4/30/25 1:06 PM, Chen Liang wrote:
>> Indeed, Joe is right. Unsigned right shift does not appear often and is
>> equivalent to signed right shift if the sign bit is 0.
>>
>> However, this piece of quote can get an upgrade - it can become
>> `Long.hashCode(this.getTime())`.
>>
>> *
>> Chen
>>
>> ------------------------------------------------------------------------
>> *From:* core-libs-dev  on behalf of
>> Joseph D. Darcy 
>> *Sent:* Wednesday, April 30, 2025 2:54 PM
>> *To:* Steffen Nie?ing ; core-libs-
>> dev at openjdk.org 
>> *Subject:* Re: JavaDoc fix in java.util.Date
>> Unsigned right shift is non-existent?
>>
>> "The operators << (left shift), >> (signed right shift), and >>>
>> (unsigned right shift) are called the shift operators. The left-hand
>> operand of a shift operator is the value to be shifted; the right-hand
>> operand specifies the shift distance. "
>>
>> https://docs.oracle.com/javase/specs/jls/se24/html/jls-15.html#jls-15.19
>> 
>>
>> -Joe
>>
>> On 4/30/2025 12:46 PM, Steffen Nie?ing wrote:
>>> Hello,
>>>
>>> I'm new to the OpenJDK community and plan to make my first change.
>>>
>>> I've found a small mistake in the documentation of
>>> java.util.Date#hashCode(). The documentation provides a Java
>>> expression of the returned value, which uses a non-existent operator
>>> '>>>'.
>>>
>>> Now I'm searching for a sponsor for a JBS issue and the code review.
>>> Chen Liang directed me to this mailing list to ask for sponsoring on
>>> this topic.
>>>
>>> Cheers,
>>> Steffen
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Wed Apr 30 20:38:59 2025
From: duke at openjdk.org (Gautham Krishnan)
Date: Wed, 30 Apr 2025 20:38:59 GMT
Subject: RFR: 8334742: Change java.time month/day field types to 'byte'
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> In the following classes, month and day values are stored in fields of type 'int' or 'short'. The range of allowed values is small enough that the type can be 'byte' instead.
> 
> java.time.YearMonth
> java.time.MonthDay
> java.time.LocalDate
> java.time.chono.HijrahDate
> 
> Refactoring the type will give the JVM a little more layout flexibility, and will be especially useful when these classes become value classes.

Gautham Krishnan has updated the pull request incrementally with one additional commit since the last revision:

  Updating copyright header

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24975/files
  - new: https://git.openjdk.org/jdk/pull/24975/files/e198afb2..148c3834

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24975&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24975&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24975.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24975/head:pull/24975

PR: https://git.openjdk.org/jdk/pull/24975

From archie.cobbs at gmail.com  Wed Apr 30 20:43:20 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Wed, 30 Apr 2025 15:43:20 -0500
Subject: JavaDoc fix in java.util.Date
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Wed, Apr 30, 2025 at 3:38?PM Steffen Nie?ing 
wrote:

> However, the docs should match the expression used in the implementation
> when explicitly naming the returned expression. Should we update both to
> Long.hashCode(this.getTime())?
>

I think that's a little too strong of a statement. Rather, if the docs
describe the behavior using an expression or sample code, the actual
behavior should be equivalent to that expression or sample code; the actual
implementation can effect that result however it wants to, as long as the
result is the same.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From naoto at openjdk.org  Wed Apr 30 20:52:45 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 30 Apr 2025 20:52:45 GMT
Subject: RFR: 8334742: Change java.time month/day field types to 'byte'
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 30 Apr 2025 20:38:59 GMT, Gautham Krishnan  wrote:

>> In the following classes, month and day values are stored in fields of type 'int' or 'short'. The range of allowed values is small enough that the type can be 'byte' instead.
>> 
>> java.time.YearMonth
>> java.time.MonthDay
>> java.time.LocalDate
>> java.time.chono.HijrahDate
>> 
>> Refactoring the type will give the JVM a little more layout flexibility, and will be especially useful when these classes become value classes.
>
> Gautham Krishnan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating copyright header

Since they are serialized fields (except Hijrah ones), I don't think this is doable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24975#issuecomment-2843247511

From asemenyuk at openjdk.org  Wed Apr 30 20:58:45 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 30 Apr 2025 20:58:45 GMT
Subject: RFR: 8352480: [macos] Don't follow symlinks in additional content
 for app images
In-Reply-To: 
References: 
Message-ID: 

On Wed, 30 Apr 2025 20:17:57 GMT, Alexander Matveev  wrote:

> - Symbolic links will not be followed for `--app-content` on macOS.
> - Added test to cover this case.
> - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG, since "cp -r" on macOS is not documented option and when used `cp` will follow symbolic links which breaks test. "cp -R" does not follow symbolic links.

I don't like the idea of changing behavior on only one platform. It should be consistent across all platforms. Let's not follow symlinks on other platforms, either.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24974#issuecomment-2843261171

From duke at openjdk.org  Wed Apr 30 20:59:49 2025
From: duke at openjdk.org (Gautham Krishnan)
Date: Wed, 30 Apr 2025 20:59:49 GMT
Subject: RFR: 8334742: Change java.time month/day field types to 'byte'
 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 30 Apr 2025 20:50:34 GMT, Naoto Sato  wrote:

>> Gautham Krishnan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating copyright header
>
> Since they are serialized fields (except Hijrah ones), I don't think this is doable.

@naotoj Thanks for reviewing.

You are right. 
But when I checked these classes use a custom Externalizable encoding (see 'readExternal'/'writeExternal'), which already stores these values as bytes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24975#issuecomment-2843263464

From naoto at openjdk.org  Wed Apr 30 21:06:47 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 30 Apr 2025 21:06:47 GMT
Subject: RFR: 8334742: Change java.time month/day field types to 'byte'
 [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 30 Apr 2025 20:57:23 GMT, Gautham Krishnan  wrote:

> But when I checked these classes use a custom Externalizable encoding (see 'readExternal'/'writeExternal'), which already stores these values as bytes.

Sorry, that is correct. Jumped the gun too soon

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24975#issuecomment-2843278253

From chen.l.liang at oracle.com  Wed Apr 30 21:07:10 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Wed, 30 Apr 2025 21:07:10 +0000
Subject: JavaDoc fix in java.util.Date
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: 

Indeed, Archie is right. There are different levels of strictness in the specification.

In this particular site, we have "the hash code is the value of the expression" which only requires the return value to be equivalent. The implementation is free to be anything.

In specifications, we usually use "equivalent" to indicate behaviors are the same but implementation code may differ. The words "the same as", "idential to" or simply "is" indicate exact matches.

-Chen
________________________________
From: core-libs-dev  on behalf of Archie Cobbs 
Sent: Wednesday, April 30, 2025 3:43 PM
To: Steffen Nie?ing 
Cc: core-libs-dev at openjdk.org 
Subject: Re: JavaDoc fix in java.util.Date

On Wed, Apr 30, 2025 at 3:38?PM Steffen Nie?ing > wrote:
However, the docs should match the expression used in the implementation when explicitly naming the returned expression. Should we update both to Long.hashCode(this.getTime())?

I think that's a little too strong of a statement. Rather, if the docs describe the behavior using an expression or sample code, the actual behavior should be equivalent to that expression or sample code; the actual implementation can effect that result however it wants to, as long as the result is the same.

-Archie

--
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rriggs at openjdk.org  Wed Apr 30 21:14:47 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 30 Apr 2025 21:14:47 GMT
Subject: RFR: 8334742: Change java.time month/day field types to 'byte'
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 30 Apr 2025 20:38:59 GMT, Gautham Krishnan  wrote:

>> In the following classes, month and day values are stored in fields of type 'int' or 'short'. The range of allowed values is small enough that the type can be 'byte' instead.
>> 
>> java.time.YearMonth
>> java.time.MonthDay
>> java.time.LocalDate
>> java.time.chono.HijrahDate
>> 
>> Refactoring the type will give the JVM a little more layout flexibility, and will be especially useful when these classes become value classes.
>
> Gautham Krishnan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating copyright header

Its recommended to set the assignee of a issue before starting working and to mark it in progress.
@gauthamkrishnanibm Please make the necessary changes to the issue to let people know you are working on it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24975#issuecomment-2843294271

From duke at openjdk.org  Wed Apr 30 21:18:47 2025
From: duke at openjdk.org (Gautham Krishnan)
Date: Wed, 30 Apr 2025 21:18:47 GMT
Subject: RFR: 8334742: Change java.time month/day field types to 'byte'
 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 30 Apr 2025 21:11:51 GMT, Roger Riggs  wrote:

>> Gautham Krishnan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating copyright header
>
> Its recommended to set the assignee of a issue before starting working and to mark it in progress.
> @gauthamkrishnanibm Please make the necessary changes to the issue to let people know you are working on it.

@RogerRiggs 
Sorry. I am not having write access to JBS as I just started contributing.
Should I discuss about the change in mailing list ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24975#issuecomment-2843302869

From roger.riggs at oracle.com  Wed Apr 30 21:24:56 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 30 Apr 2025 17:24:56 -0400
Subject: JavaDoc fix in java.util.Date
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: <54dbafaf-5cac-45d3-a5e3-2cac737dba9e@oracle.com>

Hi Steffen,

One other oddity about the shift operators in Java, they only use the 
lower 5 bits of the shift distance argument.

So,

int x = 1024;
x >>4 == 64;? and
x >> 36 == 64;

It is unusual to specify the algorithm used for hashcodes, though in 
some cases backward compatibility has forced them to be specified.

Regards, Roger


On 4/30/25 4:37 PM, Steffen Nie?ing wrote:
> Thanks, haven't seen unsigned right shift before. You're right, it 
> should be fine to use the unsigned one and hence Long.hashCode for that.
>
> However, the docs should match the expression used in the 
> implementation when explicitly naming the returned expression. Should 
> we update both to Long.hashCode(this.getTime())?
>
> Cheers,
> Steffen
>
> Chen Liang  schrieb am Mittwoch, 30. April 
> 2025 um 22:27:
>> Well, the sign has no impact here - the most significant 32 bits 
>> duplicated from the original sign bit are immediately discarded in 
>> the subsequent int cast truncation to the least significant 32 bits. 
>> However, how there is such a difference from before OpenJDK was 
>> published is still intriguing.
>> ------------------------------------------------------------------------
>> *From:* core-libs-dev  on behalf of 
>> Naoto Sato 
>> *Sent:* Wednesday, April 30, 2025 3:11 PM
>> *To:* core-libs-dev at openjdk.org 
>> *Subject:* Re: JavaDoc fix in java.util.Date
>> Interestingly, the implementation of Date.hashCode() does use the signed
>> right shift ">>".
>>
>> Naoto
>>
>> On 4/30/25 1:06 PM, Chen Liang wrote:
>> > Indeed, Joe is right. Unsigned right shift does not appear often 
>> and is
>> > equivalent to signed right shift if the sign bit is 0.
>> >
>> > However, this piece of quote can get an upgrade - it can become
>> > `Long.hashCode(this.getTime())`.
>> >
>> >?? *
>> >???? Chen
>> >
>> > 
>> ------------------------------------------------------------------------
>> > *From:* core-libs-dev  on behalf of
>> > Joseph D. Darcy 
>> > *Sent:* Wednesday, April 30, 2025 2:54 PM
>> > *To:* Steffen Nie?ing ; core-libs-
>> > dev at openjdk.org 
>> > *Subject:* Re: JavaDoc fix in java.util.Date
>> > Unsigned right shift is non-existent?
>> >
>> > "The operators << (left shift), >> (signed right shift), and >>>
>> > (unsigned right shift) are called the shift operators. The left-hand
>> > operand of a shift operator is the value to be shifted; the right-hand
>> > operand specifies the shift distance. "
>> >
>> > 
>> https://docs.oracle.com/javase/specs/jls/se24/html/jls-15.html#jls-15.19
>> > 
>> 
>> >
>> > -Joe
>> >
>> > On 4/30/2025 12:46 PM, Steffen Nie?ing wrote:
>> >> Hello,
>> >>
>> >> I'm new to the OpenJDK community and plan to make my first change.
>> >>
>> >> I've found a small mistake in the documentation of
>> >> java.util.Date#hashCode(). The documentation provides a Java
>> >> expression of the returned value, which uses a non-existent operator
>> >> '>>>'.
>> >>
>> >> Now I'm searching for a sponsor for a JBS issue and the code review.
>> >> Chen Liang directed me to this mailing list to ask for sponsoring on
>> >> this topic.
>> >>
>> >> Cheers,
>> >> Steffen
>> >
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rriggs at openjdk.org  Wed Apr 30 21:35:44 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 30 Apr 2025 21:35:44 GMT
Subject: RFR: 8334742: Change java.time month/day field types to 'byte'
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 30 Apr 2025 20:38:59 GMT, Gautham Krishnan  wrote:

>> In the following classes, month and day values are stored in fields of type 'int' or 'short'. The range of allowed values is small enough that the type can be 'byte' instead.
>> 
>> java.time.YearMonth
>> java.time.MonthDay
>> java.time.LocalDate
>> java.time.chono.HijrahDate
>> 
>> Refactoring the type will give the JVM a little more layout flexibility, and will be especially useful when these classes become value classes.
>
> Gautham Krishnan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating copyright header

I hope you've found [The OpenJDK Developers' Guide](https://openjdk.org/guide/), its a good read to know what to expect and what is expected of contributors.
Feel free to ask on the mail alias about how things work.  If you found the issue you would have seen it was already  assigned and it would be appropriate to ask.

Please continue.
As with any modification, its important to identify the tests that validate the change. In this case, the tests are in the repo under `test/jdk/java/time`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24975#issuecomment-2843334222

From vromero at openjdk.org  Wed Apr 30 21:31:45 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 30 Apr 2025 21:31:45 GMT
Subject: RFR: 8355956: Prepare javap for class file format aware access
 flag parsing [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 30 Apr 2025 18:03:29 GMT, Chen Liang  wrote:

>> A prerequisite to #24760; this was part of it, but was split out to simplify the review of the addition of `maskToAccessFlags(int, Location, CFFV)` by minimizing the changes in javap. That patch will only need to update `BasicWriter` as a result.
>> 
>> Testing: langtools/tools/javap, tier 1+2 underway
>
> 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:
> 
>  - Adapt the location APIs
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/javap-cffv-access-flags
>  - 8355956: Prepare javap for class file format aware access flag parsing

lgtm

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24955#pullrequestreview-2808494323

From liach at openjdk.org  Wed Apr 30 21:55:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 21:55:50 GMT
Subject: RFR: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner
 classes
In-Reply-To: 
References: 
Message-ID: 

On Tue, 29 Apr 2025 22:59:29 GMT, Ioi Lam  wrote:

> This is a general fix for all the "points to a static field that may hold a different value" failures related to `java/lang/invoke/MethodHandleImpl`. E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840), [JDK-8353330](https://bugs.openjdk.org/browse/JDK-8353330).
> 
> AOT-cached method handles quite often refer to the static fields in `MethodHandleImpl` or its inner classes. In the production run, if the value of these static field changes, we may have unexpected behavior related to identity of objects in these static fields. `CDSHeapVerifier` makes a very conservative check for such static fields, but sometimes gives false positives (as in the above two JBS issues)
> 
> In this PR, we AOT-initialize `MethodHandleImpl` and its inner classes. This is a more authentic snapshot of the state of `java.lang.invoke` during the assembly phase. We also avoid the need to add and maintain entries in the `cdsHeapVerifier.cpp` table.
> 
> I also added more code in `MethodHandleTest.java` to simulate potential usage patterns of `MethodHandle` by the Java core libraries. Hopefully this will reduce the likelihood for innocent core lib changes breaking the AOT assembly phase.

The tests look good to me.

src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1528:

> 1526:     }
> 1527: 
> 1528:     // Called from JVM when loading an AOT cache

Suggestion:

src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1533:

> 1531:     }
> 1532: 
> 1533:     private static void runtimeSetup() {

Suggestion:


    // Called from JVM when loading an AOT cache
    private static void runtimeSetup() {

test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/MethodHandleTest.java line 361:

> 359:         }
> 360: 
> 361:         statementEnum(MyEnum.A);

String s = statementEnum(MyEnum.A);
if (!s.equals("A")) {
    throw new RuntimeException("enum switch incorrect");
}

-------------

PR Review: https://git.openjdk.org/jdk/pull/24956#pullrequestreview-2808552024
PR Review Comment: https://git.openjdk.org/jdk/pull/24956#discussion_r2069500498
PR Review Comment: https://git.openjdk.org/jdk/pull/24956#discussion_r2069500891
PR Review Comment: https://git.openjdk.org/jdk/pull/24956#discussion_r2069515213

From liach at openjdk.org  Wed Apr 30 21:58:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 21:58:51 GMT
Subject: RFR: 8297727: Forcing LF interpretation lead to StackOverflowError
 in reflection code
In-Reply-To: <92SXp91ulmlGXdPzA4fm7FwYDNiSE-_dEVzmJIf_Ahc=.4f3667c2-59df-4cca-b66f-8036ba871e57@github.com>
References: <92SXp91ulmlGXdPzA4fm7FwYDNiSE-_dEVzmJIf_Ahc=.4f3667c2-59df-4cca-b66f-8036ba871e57@github.com>
Message-ID: 

On Wed, 23 Apr 2025 22:39:40 GMT, Chen Liang  wrote:

> When LambdaForms are interpreted, so are field lambda forms. When this happens, we may get into an infinite recursion due to field lambda forms using `MethodHandleStatics.UNSAFE` via field lambda form.
> 
> I think the best solution here is to always eagerly compile field DMH forms - we already do so for all method forms, and there is a finite number of field forms, mostly pregenerated. The reference with cast form is erroneously missed, and it is actually the culprit of this issue. Will pregenerate that in another patch.

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24835#issuecomment-2843414466

From darcy at openjdk.org  Wed Apr 30 21:59:51 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 30 Apr 2025 21:59:51 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v9]
In-Reply-To: 
References: 
 <8SHcFyjNMhqcY0TDhwiLkCO-xottmOFa4nqeCDrglTc=.4122346e-5e83-4f40-abcf-415e33d214f0@github.com>
 
 
 
Message-ID: 

On Wed, 30 Apr 2025 17:59:55 GMT, Markus KARG  wrote:

>> Could this be a Javadoc bug? What does a simple `{@inheritDoc}` do?
>
> Unfortunately the same happens. ?

The following javadoc for String's getChars method has, I believe, the desired effect:


    /**
     * {@inheritDoc CharSequence}
     * @param srcBegin {@inheritDoc CharSequence}
     * @param srcEnd   {@inheritDoc CharSequence}
     * @param dst      {@inheritDoc CharSequence}
     * @param dstBegin {@inheritDoc CharSequence}
     * @throws    IndexOutOfBoundsException {@inheritDoc CharSequence}
     */


HTH

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2069529721

From iklam at openjdk.org  Wed Apr 30 21:48:56 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 30 Apr 2025 21:48:56 GMT
Subject: RFR: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner classes
Message-ID: 

This is a general fix for all the "points to a static field that may hold a different value" failures related to `java/lang/invoke/MethodHandleImpl`. E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840), [JDK-8353330](https://bugs.openjdk.org/browse/JDK-8353330).

AOT-cached method handles quite often refer to the static fields in `MethodHandleImpl` or its inner classes. In the production run, if the value of these static field changes, we may have unexpected behavior related to identity of objects in these static fields. `CDSHeapVerifier` makes a very conservative check for such static fields, but sometimes gives false positives (as in the above two JBS issues)

In this PR, we AOT-initialize `MethodHandleImpl` and its inner classes. This is a more authentic snapshot of the state of `java.lang.invoke` during the assembly phase. We also avoid the need to add and maintain entries in the `cdsHeapVerifier.cpp` table.

I also added more code in `MethodHandleTest.java` to simulate potential usage patterns of `MethodHandle` by the Java core libraries. Hopefully this will reduce the likelihood for innocent core lib changes breaking the AOT assembly phase.

-------------

Commit messages:
 - Added more test case to increase coverage on possible core-lib usage patterns for MethodHandles
 - Merge branch 'master' into 8354890-aot-init-methodhandleimpl-and-inner-classes
 - 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner classes
 - @fisk comment -- use proper HeapAccess to load referent; Also refactor AOTReferenceObjSupport::is_enabled()
 - Merge branch 'master' into 8354897-soft-weak-references-in-aot-cache
 - @fisk offline comments -- tighten up and simplify eligibility check; @DanHeidinga comment -- renamed to MethodType::assemblySetup()
 - @DanHeidinga comments
 - @fisk comment
 - Fixed windows path issues
 - Refactored code
 - ... and 8 more: https://git.openjdk.org/jdk/compare/1313349a...0f6a2e0a

Changes: https://git.openjdk.org/jdk/pull/24956/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24956&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354890
  Stats: 176 lines in 7 files changed: 165 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24956/head:pull/24956

PR: https://git.openjdk.org/jdk/pull/24956

From iklam at openjdk.org  Wed Apr 30 21:48:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 30 Apr 2025 21:48:57 GMT
Subject: RFR: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner
 classes
In-Reply-To: 
References: 
Message-ID: 

On Tue, 29 Apr 2025 22:59:29 GMT, Ioi Lam  wrote:

> This is a general fix for all the "points to a static field that may hold a different value" failures related to `java/lang/invoke/MethodHandleImpl`. E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840), [JDK-8353330](https://bugs.openjdk.org/browse/JDK-8353330).
> 
> AOT-cached method handles quite often refer to the static fields in `MethodHandleImpl` or its inner classes. In the production run, if the value of these static field changes, we may have unexpected behavior related to identity of objects in these static fields. `CDSHeapVerifier` makes a very conservative check for such static fields, but sometimes gives false positives (as in the above two JBS issues)
> 
> In this PR, we AOT-initialize `MethodHandleImpl` and its inner classes. This is a more authentic snapshot of the state of `java.lang.invoke` during the assembly phase. We also avoid the need to add and maintain entries in the `cdsHeapVerifier.cpp` table.
> 
> I also added more code in `MethodHandleTest.java` to simulate potential usage patterns of `MethodHandle` by the Java core libraries. Hopefully this will reduce the likelihood for innocent core lib changes breaking the AOT assembly phase.

src/hotspot/share/oops/instanceKlass.cpp line 868:

> 866:     initialize(CHECK);
> 867:     return;
> 868:   }

This change is to avoid deadlock in the previous implementation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24956#discussion_r2069482737

From liach at openjdk.org  Wed Apr 30 21:58:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 21:58:53 GMT
Subject: Integrated: 8355956: Prepare javap for class file format aware access
 flag parsing
In-Reply-To: 
References: 
Message-ID: 

On Tue, 29 Apr 2025 20:43:31 GMT, Chen Liang  wrote:

> A prerequisite to #24760; this was part of it, but was split out to simplify the review of the addition of `maskToAccessFlags(int, Location, CFFV)` by minimizing the changes in javap. That patch will only need to update `BasicWriter` as a result.
> 
> Testing: langtools/tools/javap, tier 1+2 underway

This pull request has now been integrated.

Changeset: 24bc714d
Author:    Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/24bc714d5e8437c191a6e88871756acdf4b1a36f
Stats:     130 lines in 5 files changed: 50 ins; 41 del; 39 mod

8355956: Prepare javap for class file format aware access flag parsing

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/24955

From liach at openjdk.org  Wed Apr 30 21:58:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 21:58:52 GMT
Subject: RFR: 8355956: Prepare javap for class file format aware access
 flag parsing [v2]
In-Reply-To: 
References: 
 
Message-ID: <9TDdj4dBee4ZioWhudT-g0K2KGe7wApR_FQXG_Rl6QA=.9410a2cc-d9f6-4ef0-9646-50f69d1bcd1e@github.com>

On Wed, 30 Apr 2025 18:03:29 GMT, Chen Liang  wrote:

>> A prerequisite to #24760; this was part of it, but was split out to simplify the review of the addition of `maskToAccessFlags(int, Location, CFFV)` by minimizing the changes in javap. That patch will only need to update `BasicWriter` as a result.
>> 
>> Testing: langtools/tools/javap, tier 1+2 underway
>
> 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:
> 
>  - Adapt the location APIs
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/javap-cffv-access-flags
>  - 8355956: Prepare javap for class file format aware access flag parsing

Thanks for the swift review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24955#issuecomment-2843414833

From liach at openjdk.org  Wed Apr 30 21:58:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 21:58:52 GMT
Subject: Integrated: 8297727: Forcing LF interpretation lead to
 StackOverflowError in reflection code
In-Reply-To: <92SXp91ulmlGXdPzA4fm7FwYDNiSE-_dEVzmJIf_Ahc=.4f3667c2-59df-4cca-b66f-8036ba871e57@github.com>
References: <92SXp91ulmlGXdPzA4fm7FwYDNiSE-_dEVzmJIf_Ahc=.4f3667c2-59df-4cca-b66f-8036ba871e57@github.com>
Message-ID: <_vhq66DwXVv_QqdeC15VbN03mcGUpFXCBA5yY8407VY=.bf4a2d00-f075-4d6b-bc06-f32f03761355@github.com>

On Wed, 23 Apr 2025 22:39:40 GMT, Chen Liang  wrote:

> When LambdaForms are interpreted, so are field lambda forms. When this happens, we may get into an infinite recursion due to field lambda forms using `MethodHandleStatics.UNSAFE` via field lambda form.
> 
> I think the best solution here is to always eagerly compile field DMH forms - we already do so for all method forms, and there is a finite number of field forms, mostly pregenerated. The reference with cast form is erroneously missed, and it is actually the culprit of this issue. Will pregenerate that in another patch.

This pull request has now been integrated.

Changeset: e36756b2
Author:    Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/e36756b264000fe2deb95ec8f68d1571fd7653f9
Stats:     53 lines in 2 files changed: 45 ins; 8 del; 0 mod

8297727: Forcing LF interpretation lead to StackOverflowError in reflection code

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/24835

From liach at openjdk.org  Wed Apr 30 22:12:20 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 22:12:20 GMT
Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to
 class file version [v6]
In-Reply-To: 
References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
 
Message-ID: 

On Wed, 30 Apr 2025 18:17:27 GMT, Chen Liang  wrote:

>> Take the class file version to reject flags not yet defined, redefined, or obsoleted. This is useful for clients like javap to report the correct undefined flags for different class file versions.
>> 
>> A preparatory patch for javap to pass around the ClassFileFormatVersion to parse flags is available at #24955.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:
> 
>  - review: improve comments about implicit null checks
>  - Merge branch 'fix/javap-cffv-access-flags' into feature/af-cffv-parse
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - Explicit imports
>  - Wording updates
>  - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
>  - Update specs for other existing APIs
>  - Wording updates, thanks Roger
>  - Missing since
>  - Fix javap causing strictfp tests to fail
>  - ... and 17 more: https://git.openjdk.org/jdk/compare/b3af1964...10be287f

Did a trivial merge and reran the sanity tests for javap and AccessFlag.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24760#issuecomment-2843478925

From liach at openjdk.org  Wed Apr 30 22:12:20 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 22:12:20 GMT
Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to
 class file version [v7]
In-Reply-To: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com>
Message-ID: 

> Take the class file version to reject flags not yet defined, redefined, or obsoleted. This is useful for clients like javap to report the correct undefined flags for different class file versions.
> 
> A preparatory patch for javap to pass around the ClassFileFormatVersion to parse flags is available at #24955.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-cffv-parse
 - review: improve comments about implicit null checks
 - Merge branch 'fix/javap-cffv-access-flags' into feature/af-cffv-parse
 - Adapt the location APIs
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/javap-cffv-access-flags
 - 8355956: Prepare javap for class file format aware access flag parsing
 - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
 - Explicit imports
 - Wording updates
 - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse
 - ... and 21 more: https://git.openjdk.org/jdk/compare/e36756b2...b1cf4ebb

-------------

Changes: https://git.openjdk.org/jdk/pull/24760/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24760&range=06
  Stats: 159 lines in 10 files changed: 99 ins; 23 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/24760.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24760/head:pull/24760

PR: https://git.openjdk.org/jdk/pull/24760

From liach at openjdk.org  Wed Apr 30 22:26:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 22:26:30 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6]
In-Reply-To: 
References: 
Message-ID: 

> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list".

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Move intrinsic to be a subsection; just one most common function of the annotation
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
 - Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java
   
   Co-authored-by: Raffaello Giulietti 
 - Shorter first sentence
 - Updates, thanks to John
 - Refine validation and defensive copying
 - 8355223: Improve documentation on @IntrinsicCandidate

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24777/files
  - new: https://git.openjdk.org/jdk/pull/24777/files/24ed1cc1..317dd27a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24777&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24777&range=04-05

  Stats: 51812 lines in 1375 files changed: 39564 ins; 7638 del; 4610 mod
  Patch: https://git.openjdk.org/jdk/pull/24777.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24777/head:pull/24777

PR: https://git.openjdk.org/jdk/pull/24777

From liach at openjdk.org  Wed Apr 30 22:26:31 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 22:26:31 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v5]
In-Reply-To: <4cfCydBqbJcxVuRmEf7W4ehFuz_MMf_zc4k5dxpQoCU=.cc4aaf74-5a6a-4213-857b-6b5f69fb63d1@github.com>
References: 
 <4cfCydBqbJcxVuRmEf7W4ehFuz_MMf_zc4k5dxpQoCU=.cc4aaf74-5a6a-4213-857b-6b5f69fb63d1@github.com>
Message-ID: 

On Wed, 23 Apr 2025 14:12:29 GMT, Chen Liang  wrote:

>> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list".
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java
>   
>   Co-authored-by: Raffaello Giulietti 

Thanks for the suggestion. In this aspect, intrinsification is just a topic under this annotation - "intrinsic" is mainly a special identifier for hardcoded logic, but the exact purpose is unspecified, with intrinsification being the most common one.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24777#issuecomment-2843500730

From liach at openjdk.org  Wed Apr 30 23:02:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 23:02:24 GMT
Subject: RFR: 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe
 [v2]
In-Reply-To: 
References: 
 
Message-ID: <9cA1nnQ1jkBIDcNYA2w_dK7UXq3CzkRbB_rL21Ky6Ao=.732d1d52-bdc2-4c5c-abd3-31965f4fee15@github.com>

On Wed, 26 Mar 2025 16:54:39 GMT, Jaikiran Pai  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:
>> 
>>  - Add a test case, fails isWrapperInstance on mainline
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/mhp-wrapper-check-async
>>  - 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe
>
> Hello Chen, going by what's documented in the `jdk.internal.util.ReferencedKeySet`, the proposed change looks reasonable to me. Someone more familiar with that class and this area in general might have additional inputs. More importantly though, I think this will require a jtreg test to verify that the thread safety in MethodHandleProxies works as expected.

I have successfully created a test case that fails a check due to race condition on mainline. Can you review again, @jaikiran and @JornVernee?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23757#issuecomment-2843623927

From liach at openjdk.org  Wed Apr 30 23:02:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 23:02:24 GMT
Subject: RFR: 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe
 [v2]
In-Reply-To: 
References: 
Message-ID: <0aX2lfNajbJtjO0xDd2bia76z8Vmcnbv2rnsIeLsucI=.0d730be1-f035-4ac4-bffb-692f2c89d88c@github.com>

> Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set.

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:

 - Add a test case, fails isWrapperInstance on mainline
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/mhp-wrapper-check-async
 - 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23757/files
  - new: https://git.openjdk.org/jdk/pull/23757/files/eb0a3639..60404635

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23757&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23757&range=00-01

  Stats: 459290 lines in 5936 files changed: 159245 ins; 269450 del; 30595 mod
  Patch: https://git.openjdk.org/jdk/pull/23757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23757/head:pull/23757

PR: https://git.openjdk.org/jdk/pull/23757

From bpb at openjdk.org  Wed Apr 30 23:41:58 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 30 Apr 2025 23:41:58 GMT
Subject: RFR: 8355954: File.delete removes read-only files (win)
Message-ID: 

This change proposes to modify `java.io.File.delete()` so that regular files on Windows will not be deleted by default if their read-only attribute is set. A boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if desired.

-------------

Commit messages:
 - 8355954: File.delete removes read-only files (win)

Changes: https://git.openjdk.org/jdk/pull/24977/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24977&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355954
  Stats: 153 lines in 4 files changed: 129 ins; 4 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/24977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24977/head:pull/24977

PR: https://git.openjdk.org/jdk/pull/24977

From liach at openjdk.org  Wed Apr 30 23:27:22 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 23:27:22 GMT
Subject: RFR: 8355391: Use Double::hashCode in java.util.Locale::hashCode
In-Reply-To: 
References: 
Message-ID: 

On Wed, 30 Apr 2025 18:01:08 GMT, Shaojin Wen  wrote:

> Similar to #24959, java.util.Locale.hashCode can also make the same improvement.
> 
> Replace manual bitwise operations in hashCode implementations of java.util.Locale with Double::hashCode.

src/java.base/share/classes/java/util/Locale.java line 3500:

> 3498:                 h = 17;
> 3499:                 h = 37*h + range.hashCode();
> 3500:                 h = 37*h + Long.hashCode(Double.doubleToLongBits(weight));

Suggestion:

                h = 37*h + Double.hashCode(weight);

These are equivalent.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24971#discussion_r2069218063

From weijun at openjdk.org  Wed Apr 30 23:33:38 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 30 Apr 2025 23:33:38 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v4]
In-Reply-To: 
References: 
Message-ID: 

> Finalize the KDF API.

Weijun Wang has updated the pull request incrementally with two additional commits since the last revision:

 - add a positive debug log and update exception message
 - enhancing exception messages and debug outputs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24520/files
  - new: https://git.openjdk.org/jdk/pull/24520/files/a55c5069..6587d991

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=02-03

  Stats: 161 lines in 2 files changed: 158 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24520.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24520/head:pull/24520

PR: https://git.openjdk.org/jdk/pull/24520

From swen at openjdk.org  Wed Apr 30 23:27:22 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 30 Apr 2025 23:27:22 GMT
Subject: RFR: 8355391: Use Double::hashCode in java.util.Locale::hashCode
Message-ID: 

Similar to #24959, java.util.Locale.hashCode can also make the same improvement.

Replace manual bitwise operations in hashCode implementations of java.util.Locale with Double::hashCode.

-------------

Commit messages:
 - Update src/java.base/share/classes/java/util/Locale.java
 - Use Long::hashCode

Changes: https://git.openjdk.org/jdk/pull/24971/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24971&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355391
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24971/head:pull/24971

PR: https://git.openjdk.org/jdk/pull/24971

From swen at openjdk.org  Wed Apr 30 23:55:51 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 30 Apr 2025 23:55:51 GMT
Subject: RFR: 8355391: Use Long::hashCode in java.time
In-Reply-To: <6pFvkJpLIQVrGXgELkrnhDs3YgJ2-ufY6RaCA8kklkQ=.b565fc4c-994f-4329-994c-9ea11855e1bc@github.com>
References: <35NfgP2ueIq0RkDomVTj7bLtM_R-qD7spwbhpIXNFZA=.99fab560-5969-4a75-9212-52626a3e5b62@github.com>
 <6pFvkJpLIQVrGXgELkrnhDs3YgJ2-ufY6RaCA8kklkQ=.b565fc4c-994f-4329-994c-9ea11855e1bc@github.com>
Message-ID: 

On Wed, 30 Apr 2025 15:01:08 GMT, Roger Riggs  wrote:

>> Replace manual bitwise operations in `hashCode` implementations of `java.time` with `Long::hashCode`.
>
> lgtm

> @RogerRiggs, @minborg, @naotoj, thanks for the reviews. I've attached successful `tier1,2` results to the ticket. I'd appreciate it if one of you would be kind enough to also sponsor the changes.
> 
> @wenshao, thanks for the tip. I will explore if we can perform similar simplifications in `java.util` too.

I submitted PR #24971 to use Double.hashCode to do similar simplification. 

In addition, sun.nio.ch.FileKey/sun.nio.fs.UnixFileKey/sun.nio.fs.UnixFileStore in java.base can also be simplified similarly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24959#issuecomment-2843751482