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